Re: Cleveland/Cincinnati Co-location

[David Kehoe <dkehoe () pdmi com>]

Former employer was in Expedient’s DC. You can honestly do better than Expedient. Look into the Power Redundancy, 
Cooling Efficiency of the building, if the site is a purpose built DC (Expedient in Cleveland is not). Is Cloud Connect 
for backups important? Have you identified your requirements? If you need a starting point look at the following: Data 
Center Certification (from the Uptime Institute), Distance, Compliance (if needed), Level of Controlled Access, Power 
SLA, N+1 Cooling, Multi-Homed ISPs, Uptime %, Monitoring, NOC, Purpose Built DC.

Involta has a really good data center in Independence, Akron, and a very impressive site near Pittsburgh. They would 
give you the option of having Hot/Hot datacenters with their connectivity. I’m not sure if you have to be in Cleveland 
or Cincinnati, but Cyxtera has an AMAZING data center in Columbus. (The DC can withstand winds up 140 MPH, is on the 
Century Link backbone, and has a solid rubber roof with no holes or cooling systems on the roof.)

Thank you,

David Kehoe

From: NANOG <nanog-bounces () nanog org> On Behalf Of nanog-request () nanog org
Sent: Friday, January 4, 2019 7:00 AM
To: nanog () nanog org
Subject: NANOG Digest, Vol 132, Issue 4

Send NANOG mailing list submissions to
nanog () nanog org<mailto:nanog () nanog org>

To subscribe or unsubscribe via the World Wide Web, visit
https://mailman.nanog.org/mailman/listinfo/nanog<https://mailman.nanog.org/mailman/listinfo/nanog>
or, via email, send a message with subject or body 'help' to
nanog-request () nanog org<mailto:nanog-request () nanog org>

You can reach the person managing the list at
nanog-owner () nanog org<mailto:nanog-owner () nanog org>

When replying, please edit your Subject line so it is more specific
than "Re: Contents of NANOG digest..."


Today's Topics:

1. Re: Cleveland/Cincinnati Co-location
(Allen McKinley Kitchen (gmail))
2. Re: Service Provider NetFlow Collectors (Aaron)
3. Re: Cleveland/Cincinnati Co-location (Shawn Ritchie)
4. Re: Announcing Peering-LAN prefixes to customers (Andy Davidson)
5. Report on Legal Barriers to RPKI Adoption (Christopher S. Yoo)
6. 192.208.19.0/24<http://192.208.19.0/24> hijack transiting 209, 286, 3320, 5511, 6461,
6762, 6830, 8220, 9002, 12956 (Dominik Bay)
7. Re: 192.208.19.0/24<http://192.208.19.0/24> hijack transiting 209, 286, 3320, 5511,
6461, 6762, 6830, 8220, 9002, 12956 (Jeff Shultz)
8. Astronaut accidently calls 911 from space (Sean Donelan)
9. Re: Cellular backup connections (Dovid Bender)
10. Re: 192.208.19.0/24<http://192.208.19.0/24> hijack transiting 209, 286, 3320, 5511,
6461, 6762, 6830, 8220, 9002, 12956 (Job Snijders)


----------------------------------------------------------------------

Message: 1
Date: Thu, 3 Jan 2019 10:50:45 -0500
From: "Allen McKinley Kitchen (gmail)"
<allenmckinleykitchen () gmail com<mailto:allenmckinleykitchen () gmail com>>
To: "Justin M. Streiner" <streinerj () gmail com<mailto:streinerj () gmail com>>
Cc: NANOG <nanog () nanog org<mailto:nanog () nanog org>>
Subject: Re: Cleveland/Cincinnati Co-location
Message-ID: <91679AF9-E310-463C-B427-630F69C02222 () gmail com<mailto:91679AF9-E310-463C-B427-630F69C02222 () gmail 
com>>
Content-Type: text/plain; charset=us-ascii

+1 for Expedient. Not a current customer but a VERY satisfied former customer. (Decision to leave them was a foul case 
of penny-pincher mismanagement, above my pay grade and over my objections.)

..Allen

> On Jan 3, 2019, at 01:00, Justin M. Streiner <streinerj () gmail com<mailto:streinerj () gmail com>> wrote:
>
> > On Tue, 1 Jan 2019, Mitchell Lewis wrote:
> >
> > I am working on project that may involve building points of presence in Cleveland & Cincinnati. Any suggestions as 
> > to which colocation facility in each city to build in? The prime factor of consideration for this project is access 
> > to waves to places like Chicago, New York & Ashburn. It would be nice to have multiple wave provider options to 
> > choose from.
> >
> > I have been looking at Cyrus One-7thStreet in Cincinnati & Databank in Cleveland.
>
> Expedient has two facilities in Cleveland that might be worth looking at.
>
> Thank you
> jms


------------------------------

Message: 2
Date: Thu, 3 Jan 2019 10:40:44 +0900
From: Aaron <aaron_ppus () fmad com<mailto:aaron_ppus () fmad com>>
To: "Michel 'ic' Luczak" <lists () benappy com<mailto:lists () benappy com>>
Cc: Erik Sundberg <ESundberg () nitelusa com<mailto:ESundberg () nitelusa com>>, "nanog () nanog org<mailto:nanog () 
nanog org>"
<nanog () nanog org<mailto:nanog () nanog org>>
Subject: Re: Service Provider NetFlow Collectors
Message-ID:
<CABq4n+TREPexPGWJJRdgRJZSuLBhVpO9pEd5mxz+Vn7p122FaQ () mail gmail 
com<mailto:CABq4n+TREPexPGWJJRdgRJZSuLBhVpO9pEd5mxz+Vn7p122FaQ () mail gmail com>>
Content-Type: text/plain; charset="utf-8"

Throwing my hat in the ring also (vendor from fmadio)
https://github.com/fmadio/pcap2json<https://github.com/fmadio/pcap2json>

Not exactly a newflow collector, its pcap -> flowgen -> elk on a single
box, working very well so far, still work in progress.

Problem with logstash is its too slow for high flow rates. So we did
everything inside the flow generator for direct ELK bulk uploads removing
logstash completely.

Cheers
Aaron

On Mon, 31 Dec 2018 at 18:40, Michel 'ic' Luczak <lists () benappy com<mailto:lists () benappy com>> wrote:

> Don’t underestimate good old ELK
> https://www.elastic.co/guide/en/logstash/current/netflow-module.html<https://www.elastic.co/guide/en/logstash/current/netflow-module.html>
> + https://github.com/robcowart/elastiflow<https://github.com/robcowart/elastiflow>
>
> BR, ic
>
> On 31 Dec 2018, at 04:29, Erik Sundberg <ESundberg () nitelusa com<mailto:ESundberg () nitelusa com>> wrote:
>
> Hi Nanog….
>
> We are looking at replacing our Netflow collector. I am wonder what other
> service providers are using to collect netflow data off their Core and Edge
> Routers. Pros/Cons… What to watch out for any info would help.
>
> We are mainly looking to analyze the netflow data. Bonus if it does ddos
> detection and mitigation.
>
> We are looking at
> ManageEngine Netflow Analyzer
> PRTG
> Plixer – Scrutinizer
> PeakFlow
> Kentik
> Solarwinds NTA
>
>
> Thanks in advance…
>
> Erik
>
>
> ------------------------------
>
> CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files
> or previous e-mail messages attached to it may contain confidential
> information that is legally privileged. If you are not the intended
> recipient, or a person responsible for delivering it to the intended
> recipient, you are hereby notified that any disclosure, copying,
> distribution or use of any of the information contained in or attached to
> this transmission is STRICTLY PROHIBITED. If you have received this
> transmission in error please notify the sender immediately by replying to
> this e-mail. You must destroy the original transmission and its attachments
> without reading or saving in any manner. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://mailman.nanog.org/pipermail/nanog/attachments/20190103/2975478b/attachment-0001.html<http://mailman.nanog.org/pipermail/nanog/attachments/20190103/2975478b/attachment-0001.html>>

------------------------------

Message: 3
Date: Thu, 3 Jan 2019 11:21:32 -0600
From: Shawn Ritchie <me () shawnritchie com<mailto:me () shawnritchie com>>
To: "Allen McKinley Kitchen (gmail)" <allenmckinleykitchen () gmail com<mailto:allenmckinleykitchen () gmail com>>
Cc: "Justin M. Streiner" <streinerj () gmail com<mailto:streinerj () gmail com>>, NANOG
<nanog () nanog org<mailto:nanog () nanog org>>
Subject: Re: Cleveland/Cincinnati Co-location
Message-ID: <19433FF4-0E0C-4D7A-9CF2-CF385AE0AAB1 () fastmail fm<mailto:19433FF4-0E0C-4D7A-9CF2-CF385AE0AAB1 () 
fastmail fm>>
Content-Type: text/plain; charset=utf-8

On Jan 3, 2019, at 9:50 AM, Allen McKinley Kitchen (gmail) <allenmckinleykitchen () gmail 
com<mailto:allenmckinleykitchen () gmail com>> wrote:
> +1 for Expedient. Not a current customer but a VERY satisfied former customer. (Decision to leave them was a foul 
> case of penny-pincher mismanagement, above my pay grade and over my objections.)
>
> ..Allen
>
> > On Jan 3, 2019, at 01:00, Justin M. Streiner <streinerj () gmail com<mailto:streinerj () gmail com>> wrote:
> >
> > > On Tue, 1 Jan 2019, Mitchell Lewis wrote:
> > >
> > > I am working on project that may involve building points of presence in Cleveland & Cincinnati. Any suggestions as 
> > > to which colocation facility in each city to build in? The prime factor of consideration for this project is access 
> > > to waves to places like Chicago, New York & Ashburn. It would be nice to have multiple wave provider options to 
> > > choose from.
> > >
> > > I have been looking at Cyrus One-7thStreet in Cincinnati & Databank in Cleveland.
> >
> > Expedient has two facilities in Cleveland that might be worth looking at.
> >
> > Thank you
> > jms

I’m in Expedient’s Cleveland DC and will second that they’re decent.

—
Shawn

------------------------------

Message: 4
Date: Thu, 3 Jan 2019 20:08:46 +0000
From: Andy Davidson <andy () nosignal org<mailto:andy () nosignal org>>
To: Dominic Schallert <ds () schallert com<mailto:ds () schallert com>>
Cc: "nanog () nanog org<mailto:nanog () nanog org>" <nanog () nanog org<mailto:nanog () nanog org>>
Subject: Re: Announcing Peering-LAN prefixes to customers
Message-ID: <34E9593E-5004-4A01-BAFC-E56CA6520433 () nosignal org<mailto:34E9593E-5004-4A01-BAFC-E56CA6520433 () 
nosignal org>>
Content-Type: text/plain; charset="utf-8"

Hi, Dominic --

On 20/12/2018, 17:49, Dominic Schallert <ds () schallert com<mailto:ds () schallert com>> wrote:

> this might be a stupid question but today I was discussing with a colleague if
> Peering-LAN prefixes should be re-distributed/announced to direct customers/peers.
> My standpoint is that in any case, Peering-LAN prefixes should be filtered and not
> announced to peers/customers because a Peering-LAN represents some sort of
> DMZ and there is simply no need for them to be reachable by third-parties not being
> physically connected to an IXP themselves.

There are no stupid questions! It is a good idea to not BGP announce and perhaps also to drop traffic toward peering 
LAN prefixes at customer-borders, this was already well discussed in the thread. But there wasn’t a discussion on how 
we got to this point. Until the Cloudflare 2013 BGP speaker attack, that sought to flood Cloudflare’s transfer networks 
and exchange connectivity (and with it saturating IXP inter-switch links and IXP participant ports), it was common for 
IXP IPv4/6 peering LANs to be internet reachable and BGP transited.

This facilitated troubleshooting (e.g. traceroutes showing peering lan interfaces in traceroutes instead of ‘starring 
out’) and PMTUD (e.g. see recommendation in 
https://www.ripe.net/ripe/mail/archives/ipv6-wg/2011-July/001839.html<https://www.ripe.net/ripe/mail/archives/ipv6-wg/2011-July/001839.html>
 which actually asked for IXP peering LANs to be announced).

There are good reasons to announce but there are better reasons to filter. The security benefits of filtering outweigh 
the upsides on today’s internet, but fashions and best practice may further evolve over time.

Andy


--
Andy Davidson
Director, Asteroid International BV www.asteroidhq.com<http://www.asteroidhq.com>
Director, Euro-IX - The European Internet Exchange Association www.euro-ix.net<http://www.euro-ix.net>



------------------------------

Message: 5
Date: Thu, 3 Jan 2019 20:51:56 +0000
From: "Christopher S. Yoo" <csyoo () law upenn edu<mailto:csyoo () law upenn edu>>
To: "nanog () nanog org<mailto:nanog () nanog org>" <nanog () nanog org<mailto:nanog () nanog org>>
Cc: David Wishnick <dwishn () law upenn edu<mailto:dwishn () law upenn edu>>
Subject: Report on Legal Barriers to RPKI Adoption
Message-ID:
<BYAPR01MB4936273F035E0BE12EB3DCD8FD8D0 () BYAPR01MB4936 prod exchangelabs 
com<mailto:BYAPR01MB4936273F035E0BE12EB3DCD8FD8D0 () BYAPR01MB4936 prod exchangelabs com>>

Content-Type: text/plain; charset="utf-8"

As many of you know, the prospects for widespread RPKI adoption grew more promising in 2018. Cloudflare issued route 
origin authorizations ("ROAs") to cover 25% of its prefixes, including its 1.1.1.1<http://1.1.1.1> resolver and DNS 
servers. NTT began treating RPKI ROAs as if they were IRR route(6)-objects. Google announced its intention to begin 
filtering routes in early 2019. The Mutually Agreed Norms for Routing Security now has over 100 network operators 
signed on.

Still, as 2019 begins, many worry that legal issues are hindering RPKI adoption. This is especially true for North 
American networks, which have a comparatively low percentage of IPv4 space covered by ROAs, and whose ROAs are 
comparatively underutilized by parties using RPKI-based route origin validation ("ROV") to inform their routing 
decisions.

My coauthor (David Wishnick) and I have spent the past year delving into the legal issues surrounding RPKI. Today, we 
are publicizing our report on how the network operator community should address these issues. It is available 
here<https://ssrn.com/abstract=3308619<https://ssrn.com/abstract=3308619>>. If you are interested in the future of 
routing security, we encourage you to read it (or its Executive Summary). We've tried to keep the legalese to a minimum.

RPKI was a major topic of discussion at NANOG 74 and ARIN 42 in Vancouver. Going forward, we expect to continue a 
fruitful dialogue about how the network operator community can reduce the legal barriers to RPKI adoption.

Here is a summary of our recommendations:

On the ROV side of the equation, the principal legal hindrances have to do with the terms and conditions governing 
access to the RPKI repository offered by ARIN in its Relying Party Agreement ("RPA"), and in the manner it has employed 
to ensure the agreement is binding. Regarding ROV:

1. The goal of widespread ROV counsels in favor of ARIN reviewing its current approach to repository distribution, 
embodied in the RPA. We conclude that two paths would be reasonable. First, ARIN should consider dropping the RPA 
altogether. This would remove the most significant legal barriers to widespread utilization of the ARIN RPKI 
repository. Second, because the legal risks faced by ARIN in an RPA-free world are ultimately uncertain, it would also 
be reasonable for ARIN to maintain the RPA for the purposes of contractually allocating risks to the parties best 
positioned to reduce and mitigate them. If ARIN keeps the RPA, ARIN should consider removing the RPA's indemnification 
clause, instead relying solely on the RPA's disclaimers of warranties and limitations of liability, or at least 
reducing the indemnification clause's scope to eliminate the problem of moral hazard.

2. Developers of RPKI validation software should consider integrating acceptance of ARIN's RPA into their software 
workflows. ARIN recently enabled this possibility, and developers should deliberate on whether to capitalize on the 
opportunity.

3. The network operator community and ARIN should broadly publicize ARIN's policy of revising various RPA clauses for 
government entities that are prohibited from agreeing to them.

4. In addition to the important step ARIN has already taken to enable third-party software developers to integrate RPA 
acceptance into their software workflows, ARIN should consider reducing the barriers to third-party service development 
imposed by the RPA's prohibited conduct clause. Specifically, ARIN should consider methods for allowing approved 
developers to make use of RPKI information as an input into more sophisticated services.

5. Separately, ARIN should consider revising the prohibited conduct clause to allow broader distribution of information 
created with RPKI as an input for research and analysis purposes.

6. As a general alternative, the Internet community should consider whether to develop a separate corporate entity that 
would be responsible for operational aspects of RPKI repository provision. That corporation could conduct such 
activities for the North American region, or on a worldwide basis.

Regarding the ROA-issuance side of the equation, the principal legal obstacles stem from the terms and conditions found 
in ARIN's Registration Services Agreement ("RSA"), Legacy Registration Services Agreement ("LRSA"), and RPKI Terms of 
Service. Regarding these, the report recommends the following:

1. ARIN should consider adopting a pathway to provide RPKI services that would explicitly refrain from altering the 
existing balance of property and transferability rights associated with IP address allocations.

2. The network operator community and ARIN should broadly publicize ARIN's policy of revising certain RSA/LRSA and RPKI 
Terms of Service clauses for government entities that are prohibited from agreeing to them. ARIN should also begin 
presenting the RPKI Terms of Service to newly-onboarded members alongside their RSA/LRSA, so that organizations spend 
less time dealing with legal issues overall.

Separately, the report recommends that the network operator community consider whether to encourage companies and the 
federal government to include RPKI adoption in procurement best practices or requirements.

In tandem with recommendations designed to encourage adoption, the report also makes two recommendations concerning 
operational readiness for widespread RPKI deployment. Specifically:

1. To reduce any legal risks associated with RPKI, the network operator community should focus on adopting operational 
best practices. No system is 100% reliable across all contingencies; as a result, operators should prepare for outages 
and other headaches. RPKI implementations should be resilient in the face of such contingencies.

2. The five RIRs should work to ensure readiness for widespread RPKI adoption and strive to publicize deeper details on 
their service-level intentions to the Internet community.

This research is supported by NSF Award No. 1748362. The contents of the report represent our independent views, not 
those of the NSF. Any mistakes, of course, are also ours alone.


Christopher S. Yoo
John H. Chestnut Professor of Law, Communication, and Computer & Information Science
Founding Director, Center for Technology, Innovation and Competition
University of Pennsylvania Law School
3501 Sansom St.
Philadelphia, PA 19104-6204
(215) 746-8772 (o)
(215) 573-2025 (f)
csyoo () law upenn edu<mailto:csyoo () law upenn edu<mailto:csyoo () law upenn edu%3cmailto:csyoo () law upenn edu>>
http://www.law.upenn.edu/faculty/csyoo/<http://www.law.upenn.edu/faculty/csyoo/>

For more information on the Center for Technology, Innovation and Competition, see 
https://www.law.upenn.edu/institutes/ctic/<https://www.law.upenn.edu/institutes/ctic/>.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://mailman.nanog.org/pipermail/nanog/attachments/20190103/82ae6154/attachment-0001.html<http://mailman.nanog.org/pipermail/nanog/attachments/20190103/82ae6154/attachment-0001.html>>

------------------------------

Message: 6
Date: Thu, 3 Jan 2019 22:01:56 +0000
From: Dominik Bay <db () rrbone net<mailto:db () rrbone net>>
To: "nanog () nanog org<mailto:nanog () nanog org>" <nanog () nanog org<mailto:nanog () nanog org>>
Subject: 192.208.19.0/24<http://192.208.19.0/24> hijack transiting 209, 286, 3320, 5511, 6461,
6762, 6830, 8220, 9002, 12956
Message-ID: <4E73CA49-E9B1-4F26-9986-D64DE9E0DB06 () rrbone net<mailto:4E73CA49-E9B1-4F26-9986-D64DE9E0DB06 () rrbone 
net>>
Content-Type: text/plain; charset="utf-8"

I see the follwowing ASN transiting a leak concerning 192.208.19.0/24<http://192.208.19.0/24> originated by 4812

209
286
3320
5400
5511
6327
6461
6762
6830
8218
8220
8447
8551
9002
12956

The proper source is 32982 (Department of Energy).
More details to be found here: https://bgpstream.com/event/171779<https://bgpstream.com/event/171779>
And here: 
http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=192.208.19.0<http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=192.208.19.0>

Cheers,
Dominik




------------------------------

Message: 7
Date: Thu, 3 Jan 2019 14:37:28 -0800
From: Jeff Shultz <jeffshultz () sctcweb com<mailto:jeffshultz () sctcweb com>>
To: Dominik Bay <db () rrbone net<mailto:db () rrbone net>>
Cc: "nanog () nanog org<mailto:nanog () nanog org>" <nanog () nanog org<mailto:nanog () nanog org>>
Subject: Re: 192.208.19.0/24<http://192.208.19.0/24> hijack transiting 209, 286, 3320, 5511,
6461, 6762, 6830, 8220, 9002, 12956
Message-ID:
<CAGb3Bgf60fye4W5HwLXqwvv3K06sVJmBA6HNzJywsTRjVZumXg () mail gmail 
com<mailto:CAGb3Bgf60fye4W5HwLXqwvv3K06sVJmBA6HNzJywsTRjVZumXg () mail gmail com>>
Content-Type: text/plain; charset="UTF-8"

China Telecom originating a network that belongs to the agency that
controls all things nuclear in the US... nothing suspicious there.

On Thu, Jan 3, 2019 at 2:03 PM Dominik Bay <db () rrbone net<mailto:db () rrbone net>> wrote:
> I see the follwowing ASN transiting a leak concerning 192.208.19.0/24<http://192.208.19.0/24> originated by 4812
>
> 209
> 286
> 3320
> 5400
> 5511
> 6327
> 6461
> 6762
> 6830
> 8218
> 8220
> 8447
> 8551
> 9002
> 12956
>
> The proper source is 32982 (Department of Energy).
> More details to be found here: https://bgpstream.com/event/171779<https://bgpstream.com/event/171779>
> And here: 
> http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=192.208.19.0<http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=192.208.19.0>
>
> Cheers,
> Dominik


--
Jeff Shultz

--
Like us on Social Media for News, Promotions, and other information!!


<https://www.facebook.com/SCTCWEB/<https://www.facebook.com/SCTCWEB/>>
<https://www.instagram.com/sctc_503/<https://www.instagram.com/sctc_503/>>
<https://www.yelp.com/biz/sctc-stayton-3<https://www.yelp.com/biz/sctc-stayton-3>>
<https://www.youtube.com/c/sctcvideos<https://www.youtube.com/c/sctcvideos>>













_**** This message
contains confidential information and is intended only for the individual
named. If you are not the named addressee you should not disseminate,
distribute or copy this e-mail. Please notify the sender immediately by
e-mail if you have received this e-mail by mistake and delete this e-mail
from your system. E-mail transmission cannot be guaranteed to be secure or
error-free as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore does
not accept liability for any errors or omissions in the contents of this
message, which arise as a result of e-mail transmission. ****_



------------------------------

Message: 8
Date: Thu, 3 Jan 2019 17:45:00 -0500 (EST)
From: Sean Donelan <sean () donelan com<mailto:sean () donelan com>>
To: nanog () nanog org<mailto:nanog () nanog org>
Subject: Astronaut accidently calls 911 from space
Message-ID:
<nycvar.OFS.7.76.4444.1901031742280.94156 () cnex qbaryna pbz<mailto:nycvar.OFS.7.76.4444.1901031742280.94156 () cnex 
qbaryna pbz>>
Content-Type: text/plain; format=flowed; charset=US-ASCII


I was disappointed that it was just a misdial. I was looking forward to
how IP geolocation worked with 9-1-1 calls from space. I always wondered
how that altitude parameter in 911 packets was used. :-)


https://www.newsweek.com/astronaut-accidentally-calls-911-space-1276892<https://www.newsweek.com/astronaut-accidentally-calls-911-space-1276892>



------------------------------

Message: 9
Date: Thu, 3 Jan 2019 18:46:08 -0500
From: Dovid Bender <dovid () telecurve com<mailto:dovid () telecurve com>>
To: Mark Milhollan <mlm () pixelgate net<mailto:mlm () pixelgate net>>
Cc: NANOG <nanog () nanog org<mailto:nanog () nanog org>>
Subject: Re: Cellular backup connections
Message-ID:
<CAM3TTh0mNx4apFpZFTXEzW4=HUM4OQND65gW3f5V2=jtdGpVyw () mail gmail 
com<mailto:CAM3TTh0mNx4apFpZFTXEzW4=HUM4OQND65gW3f5V2=jtdGpVyw () mail gmail com>>
Content-Type: text/plain; charset="utf-8"

All,

Thanks for all of the feedback. I was on site today and noticed two things.
1) As someone mentioned it could be for static IP's they have the traffic
going to a specific location. The POP is in NJ there was a min. latency of
120ms which prob had to do with this.
2) I was watching the ping times and it looked something like this:
400ms
360ms
330ms
300ms
260ms
210ms
170ms
140ms
120ms
400ms
375ms

It seems to have been coming in "waves". I assume this has to do with "how
cellular work" and the signal. I tried moving it around by putting it down
low on the floor, moving it locations etc. and saw the same thing every
time. I am going to try Verizon next and see how it goes.



On Sat, Dec 29, 2018 at 12:13 PM Mark Milhollan <mlm () pixelgate net<mailto:mlm () pixelgate net>> wrote:

> On Fri, 28 Dec 2018, Dovid Bender wrote:
>
> > I finally got around to setting up a cellular backup device in our new
> POP.
>
> > When SSH'ing in remotely the connection seems rather slow.
>
> Perhaps using MOSH can help make the interactive CLI session less
> annoying.
>
> > Verizon they charge $500.00 just to get a public IP and I want to avoid
> > that if possible.
>
> You might look into have it call out / maintain a connection back to
> your infrastructure.
>
>
> /mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://mailman.nanog.org/pipermail/nanog/attachments/20190103/b4c3f157/attachment-0001.html<http://mailman.nanog.org/pipermail/nanog/attachments/20190103/b4c3f157/attachment-0001.html>>

------------------------------

Message: 10
Date: Fri, 4 Jan 2019 11:21:32 +0300
From: Job Snijders <job () ntt net<mailto:job () ntt net>>
To: Dominik Bay <db () rrbone net<mailto:db () rrbone net>>
Cc: "nanog () nanog org<mailto:nanog () nanog org>" <nanog () nanog org<mailto:nanog () nanog org>>
Subject: Re: 192.208.19.0/24<http://192.208.19.0/24> hijack transiting 209, 286, 3320, 5511,
6461, 6762, 6830, 8220, 9002, 12956
Message-ID:
<CACWOCC8DRPSWCvsa6n-Yyf0LwR=81APcL+HAvgOF9GHwvYhvuA () mail gmail 
com<mailto:CACWOCC8DRPSWCvsa6n-Yyf0LwR=81APcL+HAvgOF9GHwvYhvuA () mail gmail com>>
Content-Type: text/plain; charset="utf-8"

Dear all,

NTT / AS 2914 deployed explicit filters to block this BGP announcement from
AS 4134. I recommend other operators to do the same.

I’d also like to recommend AS 32982 to remove the AS_PATH prepend on the
/24 announcement so the counter measure is more effective.

Kind regards,

Job

On Fri, Jan 4, 2019 at 1:02 Dominik Bay <db () rrbone net<mailto:db () rrbone net>> wrote:

> I see the follwowing ASN transiting a leak concerning 192.208.19.0/24<http://192.208.19.0/24>
> originated by 4812
>
> 209
> 286
> 3320
> 5400
> 5511
> 6327
> 6461
> 6762
> 6830
> 8218
> 8220
> 8447
> 8551
> 9002
> 12956
>
> The proper source is 32982 (Department of Energy).
> More details to be found here: https://bgpstream.com/event/171779<https://bgpstream.com/event/171779>
> And here: 
> http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=192.208.19.0<http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=192.208.19.0>
>
> Cheers,
> Dominik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://mailman.nanog.org/pipermail/nanog/attachments/20190104/0c84b757/attachment-0001.html<http://mailman.nanog.org/pipermail/nanog/attachments/20190104/0c84b757/attachment-0001.html>>

End of NANOG Digest, Vol 132, Issue 4
*************************************