Re: Charter Porting

[Mike Hammett]

Today I got the form to fill out to gain access to their portal. Thanks for 
your help. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Mike Hammett"  
To: "NANOG"  
Sent: Friday, January 18, 2019 6:02:46 PM 
Subject: Charter Porting 


I first tried on VoiceOps, but didn't get any responses. 

Anyone have a useful contact in Charter's porting department? We've been trying 
to port a number for 10 days, but haven't been setup with their portal yet. The 
luck I'm having with the people at the e-mail address 
(charter.stl@charter.com) specified in their porting instructions web site 
(https://www.spectrum.com/policies/local-number-portability-business-rules.html)
 is about as good as building a bridge out of wet noodles. 

Can't start the port until we have access to their portal. Can't get access to 
their portal until they pull their heads out. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

Re: BGP Experiment

[Italo Cunha]

NANOG,

This is a reminder that this experiment will resume tomorrow
(Wednesday, Jan. 23rd). We will announce 184.164.224.0/24 carrying a
BGP attribute of type 0xff (reserved for development) between 14:00
and 14:15 GMT.

On Tue, Dec 18, 2018 at 10:05 AM Italo Cunha  wrote:
>
> NANOG,
>
> We would like to inform you of an experiment to evaluate alternatives
> for speeding up adoption of BGP route origin validation (research
> paper with details [A]).
>
> Our plan is to announce prefix 184.164.224.0/24 with a valid
> standards-compliant unassigned BGP attribute from routers operated by
> the PEERING testbed [B, C]. The attribute will have flags 0xe0
> (optional transitive [rfc4271, S4.3]), type 0xff (reserved for
> development), and size 0x20 (256bits).
>
> Our collaborators recently ran an equivalent experiment with no
> complaints or known issues [A], and so we do not anticipate any
> arising. Back in 2010, an experiment using unassigned attributes by
> RIPE and Duke University caused disruption in Internet routing due to
> a bug in Cisco routers [D, CVE-2010-3035]. Since then, this and other
> similar bugs have been patched [e.g., CVE-2013-6051], and new BGP
> attributes have been assigned (BGPsec-path) and adopted (large
> communities). We have successfully tested propagation of the
> announcements on Cisco IOS-based routers running versions 12.2(33)SRA
> and 15.3(1)S, Quagga 0.99.23.1 and 1.1.1, as well as BIRD 1.4.5 and
> 1.6.3.
>
> We plan to announce 184.164.224.0/24 from 8 PEERING locations for a
> predefined period of 15 minutes starting 14:30 GMT, from Monday to
> Thursday, between the 7th and 22nd of January, 2019 (full schedule and
> locations [E]). We will stop the experiment immediately in case any
> issues arise.
>
> Although we do not expect the experiment to cause disruption, we
> welcome feedback on its safety and especially on how to make it safer.
> We can be reached at disco-experim...@googlegroups.com.
>
> Amir Herzberg, University of Connecticut
> Ethan Katz-Bassett, Columbia University
> Haya Shulman, Fraunhofer SIT
> Ítalo Cunha, Universidade Federal de Minas Gerais
> Michael Schapira, Hebrew University of Jerusalem
> Tomas Hlavacek, Fraunhofer SIT
> Yossi Gilad, MIT
>
> [A] https://conferences.sigcomm.org/hotnets/2018/program.html
> [B] http://peering.usc.edu
> [C] https://goo.gl/AFR1Cn
> [D] 
> https://labs.ripe.net/Members/erik/ripe-ncc-and-duke-university-bgp-experiment
> [E] https://goo.gl/nJhmx1

RE: Contact for BART

[Marshall, Quincy]

> On Fri, Jan 18, 2019 at 5:18 PM Ben Cannon wrote:
> > What are you talking about?
>
> Inappropriate abbreviation. I mean sure, why not a NANOG Friday Fight Club, 
> but why would you want to get in a ROW (noisy argument) with BART Simpson?

Here, here… first thought BART private aviation software package 
(http://seagilbart.com), then thought BART Simpson (and then about Matt 
Groening, however you pronounce his name) , then though a Google search was the 
best answer.

Either way that FWIW that was a long drive, to get the left coast.

Q. Marshall
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---

Re: Network Speed Testing and Monitoring Platform

[Mark Tinka]

After faffing about for quite some time with Ookla and iPerf, we have
now settled on Viavi's QT-600 platform:

   
https://www.viavisolutions.com/en-us/products/qt-600-ethernet-probe-portfolio

We shall use it as a private system, primarily to activate and handover
customer services, and on rare occasions, perform post-delivery testing.

We are no longer interested in indulging endless speed tests that are
practically meaningless and leave ISP's with the burden of explaining
things they can't control.

Mark.

On 16/Jan/19 18:52, Colton Conor wrote:
> As an internet service provider with many small business and
> residential customers, our most common tech support calls are speed
> related. Customers complaining on slow speeds, slowdowns, etc.
>
> We have a SNMP and ping monitoring platform today, but that mainly
> tells us up-time and if data is flowing across the interface. We can
> of course see the link speed, but customer call in saying the are not
> getting that speed. 
>
> We are looking for a way to remotely test customers internet
> connections besides telling the customer to go to speedtest.net
> , or worse sending a tech out with a laptop to
> do the same thing.
>
> What opensource and commercial options are out there? 
>