Re: SE Mediacom reporting complete internet outage FL GA AL

[Kraig Beahn]

Mediacom Business/Residential Service starting to come back up regionally.

On Tue, Jul 10, 2018 at 11:39 AM, Kraig Beahn  wrote:

> SE Mediacom reporting complete internet outage FL GA AL
>
> 114800 EDT 07/10/2018
>
> ——
>
> FROM MEDIACOM:
>
> big issue in GA, AL, FL atm - currently under investigation... sounds like
> a major fiber cut
>
>
>


--

SE Mediacom reporting complete internet outage FL GA AL

[Kraig Beahn]

SE Mediacom reporting complete internet outage FL GA AL

114800 EDT 07/10/2018

——

FROM MEDIACOM:

big issue in GA, AL, FL atm - currently under investigation... sounds like
a major fiber cut

RE: Broadcast television in an IP world

[Kraig Beahn]

I wanted to note that, in no way shape or form was my previous message a
vendor or technology recommendation, nor do we have any direct or indirect
financial ties to either party, except that we provide the DIA fiber trunk
to pass the live video content from the studio to the GDM peering point. At
that point, it is GDM's responsibility to push the same traffic towards the
CDN aggregator or their choosing.

My message was simply an indication that portions of the broadcast industry
have recognized OTT as part of their future, regardless of how its
deployed, under what conditions or technological methods.

On Keith's note, I wont disagree with his response, except to note that it
does take at least 45Mb/s upon launching the channel, at peak, then settles
down to 12-25Mb/s for simple HD news content.

Not sure which CDN they are using but can find out, if you'd like to test
further. I am confident that they do not have Canada in their CDN mix.

On Nov 18, 2017 11:03 AM, "Keith Medcalf" <kmedc...@dessus.com> wrote:

>
> Looks OK on my old 12" 240i interlace CRT.  However, it is not High
> Definition.  Like everything on the Roku it is CATRS (Compressed All To Rat
> Shit) and motion decimated and unsuitable for display on anything
> bigger/more modern than a 12 240i CRT circa 1980 or so, and certainly
> completely unwatchable on a 80" 1080p display.
>
> And one cannot look at that SyncBak page unless one disables security and
> permits unwashed code free reign to execute willy nilly on the local
> computer.  I do not have the time nor inclination to security audit their
> code, so there is nothing to be seen from them.  This means on a balance of
> probabilities  that they are nothing more than snake-oil salesmen.
>
> ---
> The fact that there's a Highway to Hell but only a Stairway to Heaven says
> a lot about anticipated traffic volume.
>
>
> >-----Original Message-
> >From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Kraig Beahn
> >Sent: Saturday, 18 November, 2017 07:14
> >To: Luke Guillory
> >Cc: NANOG list
> >Subject: Re: Broadcast television in an IP world
> >
> >The OTT side is already being implemented by a major broadcast
> >customer of
> >ours.
> >
> >Right now they simply rebroadcast their news, both live and
> >prerecorded,
> >i'm assuming until the national networks and syndicators will allow
> >reasonable OTT licensing fee's.
> >
> >They use a product called SyncBak (for which they've also invested in
> >heavily) and offer the streams for all of their market stations
> >nationwide.
> >You can in turn use a Roku or Roku like STB to ascertain the feed,
> >live and
> >in HD at that.
> >
> >We currently provide the fiber and peering facilities, and are
> >intimately
> >familiar with the network and video production side.
> >
> >Very neat product, at that...
> >
> >IP translator and MPEG network side:
> >http://www.syncbak.com
> >
> >Example station: https://channelstore.roku.com/details/47424/wctv
> >
> >
> >
> >
> >On Nov 17, 2017 7:53 PM, "Luke Guillory" <lguill...@reservetele.com>
> >wrote:
> >
> >> Because local OTA channels are probably most of what people want
> >live
> >> outside of sporting events.
> >>
> >>
> >>
> >> Sent from my iPad
> >>
> >> On Nov 17, 2017, at 6:49 PM, Baldur Norddahl
> ><baldur.nordd...@gmail.com<
> >> mailto:baldur.nordd...@gmail.com>> wrote:
> >>
> >>
> >> Much live programming could be done without significant additional
> >burden
> >> if the community could agree on multicast delivery standards.
> >>
> >>
> >>
> >>
> >> Does multicast have any future? Netflix, YouTube, et al does not
> >use it.
> >> People want instant replay and a catalogue to select from. Except
> >for sport
> >> events, live TV has no advantage so why even try to optimize for
> >it?
> >>
> >>
> >>
> >>
> >> Luke Guillory
> >> Vice President – Technology and Innovation
> >>
> >>
> >> [cid:image4d387c.JPG@67228580.4c8bfb6f]
> ><http://www.rtconline.com>
> >>
> >> Tel:985.536.1212
> >> Fax:985.536.0300
> >> Email:  lguill...@reservetele.com
> >> Web:www.rtconline.com
> >>
> >> Reserve Telecommunications
> >> 100 RTC Dr
> >> Reserve, LA 70084
> >>
> >>
> >>
> >>
> >>
> >> Disclaimer:
> >> The information transmitted, including attachments, is intended
> >only for
> >> the person(s) or entity to which it is addressed and may contain
> >> confidential and/or privileged material which should not
> >disseminate,
> >> distribute or be copied. Please notify Luke Guillory 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. Luke Guillory
> >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.
> >>
> >>
>
>
>
>

Re: Broadcast television in an IP world

[Kraig Beahn]

The OTT side is already being implemented by a major broadcast customer of
ours.

Right now they simply rebroadcast their news, both live and prerecorded,
i'm assuming until the national networks and syndicators will allow
reasonable OTT licensing fee's.

They use a product called SyncBak (for which they've also invested in
heavily) and offer the streams for all of their market stations nationwide.
You can in turn use a Roku or Roku like STB to ascertain the feed, live and
in HD at that.

We currently provide the fiber and peering facilities, and are intimately
familiar with the network and video production side.

Very neat product, at that...

IP translator and MPEG network side:
http://www.syncbak.com

Example station: https://channelstore.roku.com/details/47424/wctv




On Nov 17, 2017 7:53 PM, "Luke Guillory"  wrote:

> Because local OTA channels are probably most of what people want live
> outside of sporting events.
>
>
>
> Sent from my iPad
>
> On Nov 17, 2017, at 6:49 PM, Baldur Norddahl  mailto:baldur.nordd...@gmail.com>> wrote:
>
>
> Much live programming could be done without significant additional burden
> if the community could agree on multicast delivery standards.
>
>
>
>
> Does multicast have any future? Netflix, YouTube, et al does not use it.
> People want instant replay and a catalogue to select from. Except for sport
> events, live TV has no advantage so why even try to optimize for it?
>
>
>
>
> Luke Guillory
> Vice President – Technology and Innovation
>
>
> [cid:image4d387c.JPG@67228580.4c8bfb6f] 
>
> Tel:985.536.1212
> Fax:985.536.0300
> Email:  lguill...@reservetele.com
> Web:www.rtconline.com
>
> Reserve Telecommunications
> 100 RTC Dr
> Reserve, LA 70084
>
>
>
>
>
> Disclaimer:
> The information transmitted, including attachments, is intended only for
> the person(s) or entity to which it is addressed and may contain
> confidential and/or privileged material which should not disseminate,
> distribute or be copied. Please notify Luke Guillory 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. Luke Guillory 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.
>
>

Re: Cellular enabled console server

[Kraig Beahn]

Netcomm NWL‑25‑02 Verizon LTE Router paired with a DLI SS20 gives you
access to 20 serial ports natively from the NWL, without the use of USB or
an intermediate technology between the router, end device and LTE interface
thus signifinactly reducing the potential for an LTE communications
failure, typical of external USB devices/routers.

We have been deploying these on our Verizon Wireless private network for
about six months now, and have been extremely impressed thus far. In
addition, the NWL also has multiple GPIO's native to the platform, a
WWAN-LTE (routable DMNR) ethernet port, usb port, etc.

On our VZW MPN contract, each site is down to $5.00/MRC. Just have to have
a minimum of 25 device on the contract to reach that pricing level.

The NWL retails for $199.00
The SS20 retails for $149.00

On Feb 24, 2017 11:10 AM, "Ben Bartsch"  wrote:

> NANOG - Are any of you running a console server to access your network
> equipment via a serial connection at a remote site?  If so, what are you
> using and how much do you like it?  I have a project where I need to stand
> up over 100 remote sites and would like a backdoor to the console just to
> be able to see what's going on with the equipment to hopefully avoid a
> truck roll for something simple like a hung device.  I need 4 console ports
> and 1 RJ45 ethernet jack.  My quick Google search landed me at
> BlackBox LES1204A-3G-R2, but I've never actually used such a device.  This
> would be for use in the USA.
>
> Thank you in advance.
>
> -ben
>

Dev. Mfg & ISP Filtering Requirements as set forth in Florida HB337/SB0870, and under similar bills in about 30 other states...

[Kraig Beahn]

There's a bill being widely circulated and passing thru various chambers of
at least 30 states right now, commonly being referred to as the HUMAN
TRAFFICKING AND CHILD EXPLOITATION PREVENTION ACT, or in Florida's case,
we're apparently calling this the "HB 337:Internet Access" bill.

Jokes, moral considerations and politics aside - Does anyone have any
further information on potentially related bills passing thru states beyond
Florida, and has anyone seriously considered the infrastructure
changes/impairments necessary to comply, in the unusual event that HB337 or
any of the many other bills in various other states passes?

Edited HB Brief: An act relating to Internet access; prohibiting covered
businesses from manufacturing, distributing, or selling certain devices
unless the device contains an active and operating filter that blocks
Internet access to specified types of sexually oriented material,
prostitution, assignation, lewdness, and human trafficking; providing for
injunctive relief for violations; providing requirements for a consumer to
have such filter deactivated; requiring a filter deactivation fee and
providing for the collection and distribution thereof; prohibiting the
distribution or sale of certain devices without filters to minors and
adults; providing criminal penalties; providing for jurisdiction to
prosecute violations; providing for continuing duties of covered
businesses; requiring covered businesses to respond to reports of obscene
material that has breached the filter; providing for civil penalties for
violations; requiring covered businesses to unblock non obscene material;
exempting certain websites from filtering; amending s. 16.56, F.S.;
authorizing the Office of Statewide Prosecution to prosecute violations;
providing an effective date.

The Full Text can be found here: FL/HB 337


On the technical side, you'd probably find yourself chuckling through this
reading exercise. However, our regulatory attorney was assured this bill
for which is currently under consideration is no laughing matter and is
being seriously considered in a multitude of state venues, while others
have been dismissive. We've initiated several calls with aide's for Rep.
Spanos, the Florida House sponsor, and from what we can tell, the bill is
far from the chopping block. Considering the technical impacts not only to
internet access device manufacturers, and the implied impacts on service
providers like ourselves, i'm surprised it hasn't garnered more attention,
nationally.

>From a curiosity perspective: The source of this bill appears to be an
individual by the name Mark "Chris" Sevier, the same individual whom has
virtually sued most of Silicon Valley, and I'll leave it at that in hopes
of being able to keep this thread on a technical/legislative tone.

NANOG note: Our objective in starting this tread is not to question the
intent, moral purpose or potential political agendas surrounding Florida
House Bill 337 or bills of similar nature, only it's technical impact on
device manufacturers, internet access providers and other alike
legislatively covered businesses, assuming passage, as currently written.
--

Re: Recent NTP pool traffic increase

[Kraig Beahn]

How much of a traffic increase?

On Dec 15, 2016 5:46 PM, "Jose Gerardo Perales Soto" <
gerardo.pera...@axtel.com.mx> wrote:

> Hi,
>
> We've recently experienced a traffic increase on the NTP queries to NTP
> pool project (pool.ntp.org) servers. One theory is that some service
> provider NTP infraestructure failed approximately 2 days ago and traffic is
> now being redirected to servers belonging to the NTP pool project.
>
> Does anyone from the service provider community have any comments?
>
> Gerardo Perales
>
>
> 
>
> NOTA: La información de este correo es de propiedad exclusiva y
> confidencial. Este mensaje es sólo para el destinatario señalado, si usted
> no lo es, destrúyalo de inmediato. Ninguna información aquí contenida debe
> ser entendida como dada o avalada por AXTEL, S.A.B. de C.V, sus
> subsidiarias o sus empleados, salvo cuando ello expresamente se indique. Es
> responsabilidad de quien recibe este correo de asegurarse que esté libre de
> virus, por lo tanto ni AXTEL, S.A.B. de C.V, sus subsidiarias ni sus
> empleados aceptan responsabilidad alguna.
> NOTE: The information in this email is proprietary and confidential. This
> message is for the designated recipient only, if you are not the intended
> recipient, you should destroy it immediately. Any information in this
> message shall not be understood as given or endorsed by AXTEL, S.A.B. de
> C.V, its subsidiaries or their employees, unless expressly so stated. It is
> the responsibility of the recipient to ensure that this email is virus
> free, therefore neither AXTEL, S.A.B. de C.V, its subsidiaries nor their
> employees accept any responsibility.
>

Re: Two BGP peering sessions on single Comcast Fiber Connection?

[Kraig Beahn]

Steering clear of the failure domain conversation, if its of any benefit -
we can at least confirm that Comcast is willing to establish /29's for
multiple BGP connections at 56 Marietta/ATL.

These circuits are written on true wholesale/transit IP service contracts,
which may be the difference.

In our experience the Comcast Enterprise/Business groups have rather rigid
circuit provisioning profiles, and even if you are able to talk an engineer
into building a customer's configuration outside of their normal "scope",
it usually comes back to haunt you at some point in the future, even if
years later.

Will send a link to the Comcast enterprise ip transit profiles separately,
for reference, in the event you were not provided such previously...Or if
Comcast wholesale is on the list, of course feel free to chime in too!





On Fri, Oct 14, 2016, 1:49 PM Bill Blackford  wrote:

> It comes down to sizing your failure domain. Any single upstream Transit
> alone means the failure domain is the whole site (making assumptions about
> your topology). As mentioned earlier, any single point of failure doesn't
> reduce your failure footprint and gives little in terms of redundancy. Now
> if you point that second router to a second provider, now you've reduced
> the size of your failure domain to a single router/Transit, not the whole
> site.
>
> -b
>
>
> On Fri, Oct 14, 2016 at 10:34 AM, Paul S.  wrote:
>
> > +1, could not have said it better.
> >
> >
> > On 10/15/2016 01:47 AM, Leo Bicknell wrote:
> >
> >> In a message written on Thu, Oct 13, 2016 at 05:48:18PM +, rar
> wrote:
> >>
> >>> The goal is to keep the single BGP router from being a single point of
> >>> failure.
> >>>
> >> I don't really understand the failure analysis / uptime calculation.
> >>
> >> There is one router on the Comcast side, which is a single point of
> >> failure.
> >>
> >> There is one circuit to your prem, which is a single point of failure.
> >>
> >> To connect two routers on your end you must terminate the circuit
> >> in a switch, which is a single point of failure.
> >>
> >> And yet, in the face of all that somehow running two routers with
> >> two BGP sessions on your end increases your uptime?
> >>
> >> The only way that would even remotely make sense is if the routers
> >> in question were horribly broken / mismanaged so (had to be?) reboot(ed)
> >> on a regular basis.  However if uptime is so important using gear
> >> with that property makes no sense!
> >>
> >> I'm pretty sure without actually doing the math that you'll be more
> >> reliable with a single quality router (elminiation of complexity),
> >> and that if you really need maximum uptime that you had better get
> >> a second circuit, on a diverse path, into a different router probably
> >> from a different carrier.
> >>
> >>
> >
>
>
> --
> Bill Blackford
>
> Logged into reality and abusing my sudo privileges.
>
--

Re: IPv4 Legacy assignment frustration

[Kraig Beahn]

The following might add some clarity, depending upon how you look at it:

We, as "core" engineers know better than to use some of the sources listed
below, tho, my suspicion is that when an engineer or local IT person, on an
edge network starts to see various types of attacks, they play wack-a-mole,
based upon outdated or incomplete data, and never think twice about
revisiting such, as, from their perspective, everything is working just
fine.

In a networking psychology test, earlier this morning, I wrote to ten
well-known colleagues that I was fairly confident didn't regularly follow
the nanog lists. Such individuals comprised of IP and IT engineers for
which manage various network sizes and enterprises, ultimately posing the
question of "Where in the world is 150.201.15.7, as we were researching
some unique traffic patterns".

*Seven out of ten came back with overseas*. Two came back with more
questions "as the address space appeared to be assigned to APNIC", but was
routed domestically.

*One came back with the correct response.* (MORENET)

Two of the queried parties were representative of major networks, one for
an entire state governmental network with hundreds of thousands of actual
users and tens of thousands of routers, the other from another major
university. (Names left out, in the event they see this message later in
the day or week)

After probing the origin of their responses, I found the following methods
or data-sources were used:

-Search Engines - by far, the worst offender. Not necessarily "the engines"
at fault, but a result of indexed sites containing inaccurate or outdated
CIDR lists.
-User generated forums, such as  "Block non-North American Traffic for
Dummies Like Me
"
(Yes - that's the actual thread name on WebMasterWorld.com, from a Sr.
Member)
-Static (or aged) CIDR web-page based lists, usually placed for advertorial
generation purposes and rarely up to date or accurate. (usually via SE's or
forum referrals)
-APNIC themselves - A basic SE search resulted in an APNIC page

that,
on it's face, appears to indicate 150.0.0.0/8 is in fact, part of the
current APNIC range.
-GitHub BGP Ranking tools: CIRCL / bgp-ranging example

(last
updated on May 16th, 2011, tho an RT lookup
 via the CIRCL tool
does shows the appropriate redirect/org)
-Several routing oriented books and Cisco examples

list
such range, for example, FR/ISBN 2-212-09238-5.
-And even established ISPs, that are publically announcing their "block list
", such as Albury's Local
ISP in Australia

The simple answer is to point IT directors, IP engineers or "the
receptionists that manages the network" to the appropriate registry
data-source, which should convince them that corrective action is
necessary, i.e. fix your routing table or firewall. The complexity begins
in trying to locate all of these people and directing them to the
appropriate data-source, which I think is an unrealistic task, even for the
largest of operators. Maybe a nanog-edge group is in order.

If the issue was beyond just a nuisance and If I were in your shoes, i'd
renumber or use an alternate range for the types of traffic affected by
such blocks, i.e. administrative web traffic trying to reach major
insurance portals. (Looks like AS2572 is announcing just over 700k IPv4
address, over about 43 ranges with only some potentially affected)

Realizing that renumbering is also extremely unrealistic, if you haven't
already reached the IPv6 bandwagon, that's an option or, if none of the
above seem reasonable, you could always put together a one-page PDF that
points these administrators to the appropriate resource to validate that
you, are in fact, part of the domestic United States.

I agree that a more accurate tool probably needs to be created for the
"general population to consume," but then again, even that solution, is
"just another tool" for the search-engines to index, and you're back at
square one.

As much as I think most of us would like to help fix this issue, I don't
know that a decent, non-invasive solution exists, at least based upon the
few hours we threw at this issue today...

On Wed, Jun 22, 2016 at 10:37 AM, Tony Finch  wrote:

> Spurling, Shannon  wrote:
>
> > It’s a problem with the miss-use of the RIR delegation of a legacy
> > block.
> >
> > The assumption that because a block is assigned to a particular RIR, all
> > users in that block have to be in that RIR’s territory, without actually
> > running a query against that RIR’s Whois database.
>
> 

Re: Verizon Wireless 4G Voice/Data

[Kraig Beahn]

So far, except having to wait for remote reboots on several hundred sites,
looking good.

Voice, Data and and the few VZW 4G Network Extenders are processing LTE
packets properly.

Thanks Alex, for the insight and update (s).

Sent via EnguiFi LTE Mobile
On Jun 14, 2016 8:05 PM, "Alex Buie" <alex.b...@frozenfeline.net> wrote:

> Issue is supposedly resolved. Please test :)
> On Jun 14, 2016 7:33 PM, "Kraig Beahn" <kr...@enguity.com> wrote:
>
>> Thanks Alex and Allen,
>>
>> All of the devices tested on our side have Florida NPA/NXX's, including
>> data only devices, which is more than likely the reason we are seeing
>> issues elsewhere across the country.
>>
>> Seems to be reports elsewhere of similar issues, however is probably
>> related to the same style MSC/HLR routing (back to Florida)
>>
>> The issue still persists, as of the timestamp of this email, tho, we did
>> confirm 911 was unaffected, at least in the North Florida territory.
>>
>> Sent via EnguiFi LTE Mobile
>> On Jun 14, 2016 7:15 PM, "Allen Kitchen" <allenmckinleykitc...@gmail.com>
>> wrote:
>>
>> > Confirming problems making or receiving calls to phone numbers with a
>> > Florida LATA, no matter where those phones actually reside. (In this
>> case,
>> > SW PA.) Verizon wireless website shows "temporarily unavailable while we
>> > upgrade our systems" on selected My Vz pages.
>> >
>> > ..Allen
>> >
>> >
>> > > On Jun 14, 2016, at 18:34, Kraig Beahn <kr...@enguity.com> wrote:
>> > >
>> > > Looks like Verizon Wireless 4G voice, intermittent data services and
>> some
>> > > 3g voices services are currently non-functional, specifically in the
>> SE,
>> > > however, seeing reports nationwide as well.
>> > >
>> > >
>> > > --
>> >
>>
>

Re: Verizon Wireless 4G Voice/Data

[Kraig Beahn]

Thanks Alex and Allen,

All of the devices tested on our side have Florida NPA/NXX's, including
data only devices, which is more than likely the reason we are seeing
issues elsewhere across the country.

Seems to be reports elsewhere of similar issues, however is probably
related to the same style MSC/HLR routing (back to Florida)

The issue still persists, as of the timestamp of this email, tho, we did
confirm 911 was unaffected, at least in the North Florida territory.

Sent via EnguiFi LTE Mobile
On Jun 14, 2016 7:15 PM, "Allen Kitchen" <allenmckinleykitc...@gmail.com>
wrote:

> Confirming problems making or receiving calls to phone numbers with a
> Florida LATA, no matter where those phones actually reside. (In this case,
> SW PA.) Verizon wireless website shows "temporarily unavailable while we
> upgrade our systems" on selected My Vz pages.
>
> ..Allen
>
>
> > On Jun 14, 2016, at 18:34, Kraig Beahn <kr...@enguity.com> wrote:
> >
> > Looks like Verizon Wireless 4G voice, intermittent data services and some
> > 3g voices services are currently non-functional, specifically in the SE,
> > however, seeing reports nationwide as well.
> >
> >
> > --
>

Verizon Wireless 4G Voice/Data

[Kraig Beahn]

Looks like Verizon Wireless 4G voice, intermittent data services and some
3g voices services are currently non-functional, specifically in the SE,
however, seeing reports nationwide as well.


--

Re: carrier grade fax boards?

[Kraig Beahn]

100% Dialogic, we are currently using both of their carrier-grade boards
and IMG's to deliver fax services in various flavors of transport
configurations to end-users and wholesale customers.

Pricey, but well worth every penny...

MSP/FSP -
https://www.dialogic.com/en/products/fax-boards-and-software/foip/fsp.aspx
IMG series w/SS7 support -
https://www.dialogic.com/en/products/gateways.aspx



On Thu, Apr 28, 2016 at 12:30 AM, Ryan Finnesey  wrote:

> I was wondering if anyone had any recommendations on carrier grade fax
> boards that are SIP based?
>
> Cheers
> Ryan
>
>

Re: CALEA Requirements

[Kraig Beahn]

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

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

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

Re: Cogent issues ?

[Kraig Beahn]

We have test facilities, specifically in the Cogent Atlanta Colo - and are
not seeing any reachability issues at this point. Tested via Cogent from
alternate networks.

Will keep an eye on it tho...





On Tue, Feb 2, 2016 at 9:43 AM, Chaim Rieger  wrote:

> Having difficulty reaching various Cogent colos, in the US. (Atlanta, LA,
> DC).

Re: Is it normal for your provider to withhold BGP peering info until the night of the cut?

[Kraig Beahn]

"This carrier said that they don't provide this until the night of the
cut." / "Is this a common SOP nowadays?" - Not in our experience.

On Thu, Jan 21, 2016 at 4:26 PM, c b  wrote:

> We have 4 full-peering providers between two data centers. Our accounting
> people did some shopping and found that there was a competitor who came in
> substantially lower this year and leadership decided to swap our most
> expensive circuit to the new carrier.
> (I don't know what etiquette is, so I won't name the carrier... but it's a
> well-known name)
> Anyways, we were preparing for the circuit cutover and asked for the BGP
> peering info up front like we normally do. This carrier said that they
> don't provide this until the night of the cut. Now, we've done this 5 or 6
> times over the years with all of our other carriers and this is the first
> one to ever do this. We even escalated to our account manager and they
> still won't provide it.
> I know it's not a huge deal, but life is so much easier when you can
> prestage your cut and rollback commands. In fact, our internal Change
> Management process mandates peer review all proposed config changes and now
> we have to explain why some lines say TBD!
> Is this a common SOP nowadays? Anyone care to explain why they wouldn't
> just provide it ahead of time?
> Thanks in advance.
> CWB

Comcast Outages?

[Kraig Beahn]

Anyone in the SE seeing and/or hearing of any massive Comcast outages
regionally?

(Fiber, Voice  DOCSIS modems from Atlanta, GA to Tallahassee, FL and in
some select areas Jacksonville, FL...)

Re: Sprint v. Cogent, some clarity facts

[Kraig Beahn]

Cogent transition or prep work this morning? AS 2914 NTT?

Anyone else seeing similar changes abroad?


 CORE INFRASTRUCTURE AFFECTING ALERT *

--

BGP Status Change Sequence No: 1225957222

--

Change Status Type   : origin / Origin Set Change

--

BGP Monitored Prefix : 63.166.22.0/24

--

Update/Detection Time: 1225942611 / 1225957221 BGP ASN Update Time  :
1225942611

--

BGP Set  : 1239

--

BGP Gain(s)  : 1239

--

BGP Loss(s)  :

--

Originating Entity   : Synips / L2Networks

--



 CORE INFRASTRUCTURE AFFECTING ALERT *

--

BGP Status Change Sequence No: 1225957222

--

Change Status Type   : last-hop / Last Hop Change

--

BGP Monitored Prefix : 63.166.22.0/24

--

Update/Detection Time: 1225942611 / 1225957221 BGP ASN Update Time  :
1225942611

--

BGP Set  : 2914

--

BGP Gain(s)  : 2914

--

BGP Loss(s)  :

--

Originating Entity   : Synips / L2Networks

--

OrgName:NTT America, Inc.
OrgID:  NTTAM-1 http://ws.arin.net/whois/?queryinput=O%20!%20NTTAM-1
Address:8005 South Chester Street
Address:Suite 200
City:   Centennial
StateProv:  CO
PostalCode: 80112
Country:US

ReferralServer: rwhois://rwhois.gin.ntt.net:4321/

ASNumber:   2914
ASName: NTT-COMMUNICATIONS-2914
http://ws.arin.net/whois/?queryinput=A%20.%20NTT-COMMUNICATIONS-2914
ASHandle:   AS2914 http://ws.arin.net/whois/?queryinput=A%20!%20AS2914
Comment:
RegDate:1998-12-07
Updated:2006-09-06

RTechHandle: PEERI-ARINhttp://ws.arin.net/whois/?queryinput=P%20!%20PEERI-ARIN
RTechName:   Peering
RTechPhone:  +1-303-645-1900
RTechEmail:  [EMAIL PROTECTED]

OrgAbuseHandle:
NAAC-ARINhttp://ws.arin.net/whois/?queryinput=P%20!%20NAAC-ARIN
OrgAbuseName:   NTT America Abuse Contact
OrgAbusePhone:  +1-800-551-1630
OrgAbuseEmail:  [EMAIL PROTECTED]

OrgNOCHandle: NASC-ARINhttp://ws.arin.net/whois/?queryinput=P%20!%20NASC-ARIN
OrgNOCName:   NTT America Support Contact
OrgNOCPhone:  +1-800-551-1630
OrgNOCEmail:  [EMAIL PROTECTED]

OrgTechHandle: 
VIPAR-ARINhttp://ws.arin.net/whois/?queryinput=P%20!%20VIPAR-ARIN
OrgTechName:   VIPAR
OrgTechPhone:  +1-303-645-1900
OrgTechEmail:  [EMAIL PROTECTED]

Cogent, Sprint and NTT?

[Kraig Beahn]

 Cogent transition or prep work this morning? AS 2914 NTT?

Anyone else seeing similar changes abroad?


 CORE INFRASTRUCTURE AFFECTING ALERT *

--

BGP Status Change Sequence No: 1225957222

--

Change Status Type   : origin / Origin Set Change

--

BGP Monitored Prefix : 63.166.22.0/24

--

Update/Detection Time: 1225942611 / 1225957221 BGP ASN Update Time  :
1225942611

--

BGP Set  : 1239

--

BGP Gain(s)  : 1239

--

BGP Loss(s)  :

--

Originating Entity   : Synips / L2Networks

--



 CORE INFRASTRUCTURE AFFECTING ALERT *

--

BGP Status Change Sequence No: 1225957222

--

Change Status Type   : last-hop / Last Hop Change

--

BGP Monitored Prefix : 63.166.22.0/24

--

Update/Detection Time: 1225942611 / 1225957221 BGP ASN Update Time  :
1225942611

--

BGP Set  : 2914

--

BGP Gain(s)  : 2914

--

BGP Loss(s)  :

--

Originating Entity   : Synips / L2Networks

--

OrgName:NTT America, Inc.
OrgID:  NTTAM-1 http://ws.arin.net/whois/?queryinput=O%20!%20NTTAM-1
Address:8005 South Chester Street
Address:Suite 200
City:   Centennial
StateProv:  CO
PostalCode: 80112
Country:US

ReferralServer: rwhois://rwhois.gin.ntt.net:4321/

ASNumber:   2914
ASName: NTT-COMMUNICATIONS-2914
http://ws.arin.net/whois/?queryinput=A%20.%20NTT-COMMUNICATIONS-2914
ASHandle:   AS2914 http://ws.arin.net/whois/?queryinput=A%20!%20AS2914
Comment:
RegDate:1998-12-07
Updated:2006-09-06

RTechHandle: PEERI-ARINhttp://ws.arin.net/whois/?queryinput=P%20!%20PEERI-ARIN
RTechName:   Peering
RTechPhone:  +1-303-645-1900
RTechEmail:  [EMAIL PROTECTED]

OrgAbuseHandle:
NAAC-ARINhttp://ws.arin.net/whois/?queryinput=P%20!%20NAAC-ARIN
OrgAbuseName:   NTT America Abuse Contact
OrgAbusePhone:  +1-800-551-1630
OrgAbuseEmail:  [EMAIL PROTECTED]

OrgNOCHandle: NASC-ARINhttp://ws.arin.net/whois/?queryinput=P%20!%20NASC-ARIN
OrgNOCName:   NTT America Support Contact
OrgNOCPhone:  +1-800-551-1630
OrgNOCEmail:  [EMAIL PROTECTED]

OrgTechHandle: 
VIPAR-ARINhttp://ws.arin.net/whois/?queryinput=P%20!%20VIPAR-ARIN
OrgTechName:   VIPAR
OrgTechPhone:  +1-303-645-1900
OrgTechEmail:  [EMAIL PROTECTED]

May be just a 'fluke', but we thought the timing was odd.

Hope all is well,

Kraig

Sprint Core Router Powered Down in Orlando, Fl?

[Kraig Beahn]

Was curious if any other SP's were affected by an issue starting this
afternoon and lasting about 10 minutes whereas a Sprint technician
accidentally bumped the DC distribution panel feeding their core Switching
and Routing platform in Orlando, FL? One of our customer's transit pipe's as
well as their core MPLS network were affected nationwide (due to the
position of their datacenter physically).

Of more interest does anyone know what the 'official' Sprint internal
maintenance window policies are? Trying to hunt down some definitive answers
for the powers that be...

Thanks,

Kraig


Packets   Pings

 Host Loss%   Snt   Last   Avg  Best
Wrst StDev

 1. tengige-atl-gi1.l2ix.com   0.0%150.2   0.2   0.2
0.3   0.0

 2. fa0-15.na01.b000173-0.atl01.atlas.cog  0.0%150.7   0.8   0.6
1.2   0.2

 3. gi2-0.3801.core01.atl01.atlas.cogentc  0.0%150.6  14.8   0.4
133.2  38.8

 4. po4-0.core01.dca01.atlas.cogentco.com  0.0%15   12.7  12.9  12.7
13.5   0.2

 5. te3-1.ccr02.dca01.atlas.cogentco.com   0.0%15   12.8  13.0  12.8
13.2   0.1

 6. te4-3.mpd01.dca02.atlas.cogentco.com   6.7%15   13.8  13.8  13.5
15.2   0.5

 7. te3-2.ccr02.iad01.atlas.cogentco.com   0.0%15   13.8  13.9  13.6
15.7   0.5

 8. gi2-0-0.core01.iad01.atlas.cogentco.c  0.0%15   13.6  13.5  13.4
13.6   0.1

 9. sprint.iad01.atlas.cogentco.com0.0%15   13.8  13.8  13.7
13.9   0.1

10. sl-bb21-dc-8-0-0.sprintlink.net0.0%15   14.7  14.8  14.6
14.9   0.1

11. sl-crs2-dc-0-4-0-0.sprintlink.net  0.0%15   15.4  15.2  14.9
15.9   0.3

12. sl-crs2-ffx-0-4-0-0.sprintlink.net 0.0%15   26.0  26.1  25.9
26.5   0.2

13. 144.232.19.249 0.0%15   33.5  33.7  33.5
34.1   0.2

*14. sl-gw15-orl-14-0.sprintlink.net   14.3%15  244.5 245.3 244.4
247.1   0.9*

15. sl-bb20-orl-14-3.sprintlink.net7.1%15  250.3 250.3 244.5
304.7  16.4

16. sl-gw12-orl-8-0.sprintlink.net 7.1%15  244.2 244.9 244.2
246.4   0.7

17. sl-wbko-3-0.sprintlink.net 7.1%14  253.9 254.2 253.7
256.4   0.8

18. fwgw-gig-sl3-pos2.gray.tv  0.0%14  255.6 254.7 253.7
255.6   0.7

Re: [NANOG] Sprintlink ATL-MCO?

[Kraig Beahn]

New to the list, however there is a master ticket open w/Sprint (TK#2172676)
for a fiber cut in DC. Verizon was dispatched to the site, in which they
supposedly had to gain authorization from the Railroad to even work on the
facilities with an on-site time of Noon Central.

Sprint did not provide an ETA and stated they would be unable to do so until
Verizon reported back. All of their Miami traffic was in turn routed via
Orlando to Atlanta, etc.

We have two DS3's in Tallahassee (Fed from Orlando), Florida and a Gigabit
connection in Atlanta and all of the above have been and are still affected
by the transition.

This apparently affected their DC - Miami operations.

Hope this helps!

Kraig


On 5/12/08, Alan Halachmi [EMAIL PROTECTED] wrote:

 I'm seeing a significant slowdown between Atlanta and Orlando.  Anyone
 else?

 1 ...
 2 ...
 3 ...
 4 ...
 5 ...
 6  POS5-1.GW4.NYC4.ALTER.NET (157.130.14.177)  10 ms  15 ms  33 ms
 7  146.at-2-0-0.XR3.NYC4.ALTER.NET (152.63.25.98)  26 ms  4 ms  4 ms
 8  0.so-4-0-2.XL3.NYC4.ALTER.NET (152.63.17.29)  3 ms  3 ms  3 ms
 9  0.ge-6-1-0.BR3.NYC4.ALTER.NET (152.63.3.166)  4 ms  3 ms  4 ms
 10  sl-crs2-nyc-0-1-2-0.sprintlink.net (144.232.18.237)  4 ms  23 ms  17
 ms
 11  sl-crs1-pen-0-4-5-0.sprintlink.net (144.232.20.142)  21 ms  27 ms  23
 ms
 12  sl-bb21-rly-15-0.sprintlink.net (144.232.20.208)  25 ms  24 ms  17 ms
 13  sl-bb21-dc-5-0-0.sprintlink.net (144.232.8.164)  31 ms  33 ms  28 ms
 14  sl-crs1-dc-0-4-0-0.sprintlink.net (144.232.15.13)  45 ms  54 ms  50 ms
 15  sl-crs1-atl-0-8-0-1.sprintlink.net (144.232.8.146)  291 ms  283
 ms  285
 ms
 16  sl-bb21-orl-2-0.sprintlink.net (144.232.20.87)  500 ms  525 ms *
 17  sl-bb20-orl-15-0.sprintlink.net (144.232.0.98)  489 ms  489 ms  489 ms
 18  sl-gw12-orl-8-0.sprintlink.net (144.232.2.178)  487 ms  486 ms  486 ms

 Best,
 Alan

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

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