Re: Sept. 30 Verizon outage

[Eric Kuhnke]

Not related to Verizon or outages at all (though it certainly was going to
be a very expensive and large scale outage at the time), there's a
fascinating book about the group of investors and people who formed a new
group to acquire the "v1.0" Iridium network out of bankruptcy, turn it into
a DoD essential service/US government contractor, and run the second
corporate incarnation of Iridium.

https://www.amazon.ca/Eccentric-Orbits-Iridium-John-Bloom/dp/0802121683

https://groveatlantic.com/book/eccentric-orbits/

On Tue, Oct 1, 2024 at 12:36 PM Aaron Groom 
wrote:

> That will be an interesting read.
>
> I recently read the book "Rogers v Rogers" that covers the major Rogers
> Communications outage in Canada from a couple years ago.  The book is
> mostly biographical, but it lays a good historical foundation for those
> events.
>
> Anyone else have any good book recommendations?
>
> Jared Mauch  writes:
>
> > Due to the scale of this I would expect an outage report to appear with
> the FCC in the next year.
> >
> > I do think this highlights the increased frequency and impact of these
> outages.
> >
> > Make sure you have backup plans for communications if one or more
> > fails. While my personal impact was near nil many people use telemetry
> > or navigation over cellular as a service and would have been
> > impacted. If I was for example an uber driver impacted I may not be
> > able to reach my destination, or I may not be able to summon one.
> >
> > As the market squeezes margins our tolerance for faults also
> > narrows. We saw this with supply chains 2020-present and I expect the
> > rate will increase vs decrease in the coming years where a disruption
> > has unexpected impacts.
> >
> > Role play these outages and test them where possible.
> >
> > - Jared
> >
> > Sent via RFC1925 compliant device
> >
> >> On Oct 1, 2024, at 12:16 PM, Andy Ringsmuth  wrote:
> >>
> >> Now that this is behind us, I’m wondering if anyone has heard what
> actually happened.
> >>
> >> Does Verizon do after-action reports that we could find?
> >>
> >> 
> >> Andy Ringsmuth
> >> 5609 Harding Drive
> >> Lincoln, NE 68521-5831
> >> (402) 202-1230
> >> a...@andyring.com
>

Re: Unlocked ATT copper cabinet in Austin TX

[Eric Kuhnke]

The unfortunate reality is that copper last mole ILECs have a strong
economic incentive to *allow* things like copper cabinets to become
decrepit and degraded, because once they have successfully migrated the
final customers off copper in an area, they can abandon (and recycle) it.

The cost to fix something like what you've described is quite a lot for the
fully amortized truck roll and employee labor hours.

I would be shocked if it gets fixed proactively before it becomes a total
outage situation. Maybe if it gets obliterated by a car at 3 in the
morning.

You should see the scary photos of copper cross box cabinets that get
posted every day to low voltage tech and field tech oriented social media
groups...



On Sun, Aug 11, 2024, 1:44 PM Chris Boyd  wrote:

> If anyone on the list knows how to get info to ATT local repair in Austin
> TX, specifically the Hickory CO, I’d appreciate you forwarding this info.
> All the repair pages want a local ATT number to report problems now, and
> I’m no longer an ATT customer.
>
> The copper cabinet on Monroe near Travis Heights boulevard is unlocked and
> open. The copper cabinet is next to a fiber node labeled XR0416.
>
> https://imgur.com/a/n8bB2tJ

Re: Server rental inside of One Wilshire in Los Angeles

[Eric Kuhnke]

I completely agree, the original "rfq" is super suspicious. There's no need
to require to be specifically at One Wilshire for a single 1U server
(particularly with only 10GbE interfaces, not 100), since the most
effective use of being at a major interconnect point like that is only if
you're prepared to incur the recurring monthly expense of many
intra-building cross connects.

Realistic use by a small ISP that needs a presence there would be more like
a minimum 1/4th of a cabinet in its own compartment.


On Wed, Aug 7, 2024, 6:38 PM William Herrin  wrote:

> On Wed, Aug 7, 2024 at 4:07 PM Eric Kuhnke  wrote:
> > Your typical cat 6A cable is significantly fatter in diameter, less
> flexible and [...]
>
> Hi Eric,
>
> All of these are excellent reasons why the DC -operator- should want
> to use fiber in 10GE links.
>
> The question was: why does a DC -customer- want 40 gigs of
> specifically fiber optic connections in what is otherwise a minimum
> server configuration, the sort that easily fits in 1U. The Linux
> network stack would struggle to even drive 40 gigs; you'd be into very
> custom network software built with something like DPDK but the guy
> hasn't placed any conditions on the available network infrastructure
> and connectivity except that it offer 4x 10gig fiber optic ethernet.
> That's weird.
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
>

Re: Server rental inside of One Wilshire in Los Angeles

[Eric Kuhnke]

>From a strictly physical cabling point of view, while 10GBaseT is likely to
work on ordinary cat5e or cat 6 cabling at very short distances such as
from a server to a top of rack aggregation switch, more successful results
will be seen with cat6a.

Your typical cat 6A cable is significantly fatter in diameter, less
flexible and takes up much more space inside vertical cabling management up
and down the inside of a dense cabinet, compared to an ordinary figure-8
shaped duplex singlemode fiber patch cable. And even more space savings are
possible with single tube/uniboot, 1.6 mm diameter patch cables.


On Wed, Aug 7, 2024, 3:48 PM Saku Ytti  wrote:

> On Wed, 7 Aug 2024 at 17:41, Brandon Martin 
> wrote:
>
> > Among the other reasons folks have given, the 10GBASE-T PHY has added
> > latency beyond the basic packetization/serialization delay inherent to
> > Ethernet due to the use of a relatively long line code plus LDPC.  It's
> > not much (2-4us which is still less than 1000BASE-T
> > serialization+packetization latency with larger packets), but it's more
> > than 10GBASE-R PHYs.  The HFT guys may care, but most other folks
> > probably don't give a hoot.
>
> I think this is the least bad explanation, some explanations are that
> copper may not be available, but that doesn't explain preference. Nor
> do I think wattage/heat explains preference, as it's hosted, so
> customers probably shouldn't care. Latency could very well explain
> preference, but it seems doubtful, when hardware is so underspecified,
> surely if you are talking in single microseconds or nanoseconds
> budget, the actual hardware becomes very important, so i think lack of
> specificity there implies it's not about latency.
>
> --
>   ++ytti
>

MA statewide 911 outage and resolved shortly afterwards?

[Eric Kuhnke]

Via the Outages list, info from the Boston police department followed about
an hour later by a "it's fixed" message.

Did anyone in MA receive a push notification from their cellular carrier?


Quotation from original posts follows

"I have a report this 3pm Tue, hour from the authenticated FB page of the
Boston PD,
that 9-1-1 service is out statewide in Mass; they're handling it as a Code
2 AHOD;
flag down a cruiser if you need help.

"""
9-11 is currently down statewide.

If you are experiencing an emergency please pull a Fire Box.

If you need assistance, please reach out to your local Boston Police
District station.

Boston Police will be patrolling with their blue lights activated for high
visibility.
Please approach an officer if you need assistance:

Downtown A-1: (617) 343-4240
Charlestown A-15: (617) 343-4888
East Boston A-7: (617) 343-4220
Roxbury B-2: (617) 343-4270
Mattapan B-3: (617) 343-4700
South Boston C-6: (617) 343-4730
Dorchester C-11: (617) 343-4330
South End D-4: (617) 343-4250
Allston/Brighton D-14: (617) 343-4260
Roslindale/ West Roxbury E-5: (617) 343-4560
Jamaica Plain E-13: (617) 343-5630
Hyde Park E-18: (617) 343-5600



911 Operating System is back up and running

CANCEL 9-11 is currently down statewide.

If you are experiencing an emergency please pull a Fire Box.

If you need assistance, please reach out to your local Boston Police
District station.

Boston Police will be patrolling with their blue lights activated for high
visibility.

Please approach an officer if you need assistance:

Downtown A-1: (617) 343-4240

Charlestown A-15: (617) 343-4888

East Boston A-7: (617) 343-4220

Roxbury B-2: (617) 343-4270

Mattapan B-3: (617) 343-4700

South Boston C-6: (617) 343-4730

Dorchester C-11: (617) 343-4330

South End D-4: (617) 343-4250

Allston/Brighton D-14: (617) 343-4260

Roslindale/ West Roxbury E-5: (617) 343-4560

Jamaica Plain E-13: (617) 343-5630

Hyde Park E-18: (617) 343-5600

Re: ru tld down?

[Eric Kuhnke]

Not necessarily saying these are related, but given the current
geopolitical situation, not beyond the realm of possibility that this is
the result of 'something else' gone wrong.

https://www.google.com/search?&q=russia+internet+disconnection+test


On Tue, Jan 30, 2024 at 8:11 AM Bill Woodcock  wrote:

>
>
> > On Jan 30, 2024, at 17:00, Dmitry Sherman  wrote:
> >
> > ru tld down?
>
> Not exactly down…  they just busted their DNSSEC, or their domain got
> hijacked or something.  Bad DNSKEY records.
>
> -Bill
>
>

Re: IPv4 address block

[Eric Kuhnke]

I might note that one of the qualified facilitators on the list recently
"sold" me a block where the original entity which obtained it in the 1990s
was still announcing it to all of their peers and trantsi after the wire
transfer had been done, the ARIN process was done/ticket closed, and the
block resided with my AS.

It took a significant amount of badgering the original block holder (an
entity with which we had no pre-existing relationship or direct contacts
into their engineering department) to get them to withdraw the
announcement, which we did independently of the broker and quicker than
they responded to us. So my message would be to do your own due diligence
and investigation of IP space and don't trust what the "broker" tells you.



On Sun, Jan 7, 2024 at 8:50 PM John Curran  wrote:

> On Jan 7, 2024, at 7:46 PM, KARIM MEKKAOUI  wrote:
>
> Hi Nanog Community
>
> Any idea please on the best way to buy IPv4 blocs and what is the price?
>
>
> Karim -
>
> Many folks make use of a broker for the purpose of finding an IPv4 address
> block – ARIN refers to organizations that aid others with transfers of
> address blocks as “facilitators”.
>
> As a result of community concerns regarding less than stellar performance
> of some ARIN-listed facilitators, we recently relaunched the ARIN
> facilitator program with significantly more robust legal, accountability
> and transparency requirements –
> https://www.arin.net/resources/registry/transfers/facilitators/#qualified-facilitator-requirements
>
>
> This has resulted in a significant reduction in the number of
> organizations listed by ARIN as Qualified Facilitators, but there are
> plenty that meet the higher operational and customer satisfaction criteria
> and can be found here –
> https://www.arin.net/resources/registry/transfers/facilitators/qualifiedfacilitators/
> –  any of them should be able to do a credible job in helping you obtain an
> IPv4 address block from the marketplace.
>
> Best wishes,
> /John
>
> John Curran
> President and CEO
> American Registry for Internet Numbers
>
>
>

Feds seek to seize funds from lv.net ISP bank accounts and allege $3+ million fraud in bitcoin

[Eric Kuhnke]

https://storage.courtlistener.com/recap/gov.uscourts.nysd.590823/gov.uscourts.nysd.590823.62.0.pdf

https://www.google.com/search?q=lv.net+ISP+nevada

It's a fairly well known regional ISP...

Re: Outside plant - prewire customer demarc preference

[Eric Kuhnke]

If anyone assumes that residential real estate general contractors and low
voltage/wiring subcontractors know or care about wifi signal or not putting
RF units inside metal boxes - that would be a bad assumption to make.


On Thu, Dec 7, 2023 at 10:18 PM Jay Hennigan  wrote:

> On 12/6/23 23:22, Eric Kuhnke wrote:
> > I think an important point for pre-wire and residential real estate
> > developers to consider is also the conflicting needs of keeping things
> > "neat and tidy" and last mile CPE location vs wifi coverage.
>
> If you assume that the appropriate place for a wifi access point is
> colocated with the NID/ONT/CPE, you're doing it wrong.
>
> --
> Jay Hennigan - j...@west.net
> Network Engineering - CCIE #7880
> 503 897-8550 - WB6RDV
>
>

Re: Outside plant - prewire customer demarc preference

[Eric Kuhnke]

I think an important point for pre-wire and residential real estate
developers to consider is also the conflicting needs of keeping things
"neat and tidy" and last mile CPE location vs wifi coverage.

Your typical new build residential construction will have something like
this in it for telecom purposes:

https://imgur.com/RDMn6px

Or like this:

https://www.reddit.com/media?url=https%3A%2F%2Fi.redd.it%2F65wgbfel14m91.jpg

And then people install their ISP CPE in it and an 802.11ac (or ax) 2x2 or
3x3 router, often this is the same device, and wonder why their performance
is bad because the wifi AP happens to be **inside a box with a metal door
on it**.

Or the ISP tech knows better and tells people that their wifi coverage will
be terrible with the CPE inside of the box, so some sort of hack-job is
necessary to get power and ethernet to the location where the dual-band AP
can be located for optimal whole-home coverage.

Some of these now are all plastic and don't block as much 5 GHz signal, so
it's not quite as bad...





On Tue, Dec 5, 2023 at 7:46 PM Sean Donelan  wrote:

>
> You've misunderstood the goal.
>
> The intent is not to protect the fiber, but to make it easier for the
> field tech installing new service in a neat way through finished
> construction and concealled raceways, without cutting sheetrock or
> stapling exposed cabling across walls.
>
> Trying to prevent the next "bad fiber install" set of pictures.
>
> U.S. NEC does not require any mechanical protection for fiber cables.  You
> can run "bare" fiber cables through most residential spaces (with a few
> exceptions for jacket material, i.e. direct burial cable not allowed
> inside habital spaces).  Building codes may vary in other countries.
>
> On the other hand, do some searches for "bad fiber install" for many
> examples of fiber installers stapling fiber around the outside of houses
> or zip-tied to gas pipes.
>
>
>
> On Tue, 5 Dec 2023, Martin Hannigan wrote:
> > 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.
>

Re: CPE/NID options

[Eric Kuhnke]

For ISPs buying this sort of white box/OEM platform in large quantities, I
would recommend sending one person to attend the yearly Computex Taipei
trade show to look at the new stuff and meet the manufacturer reps in
person.

Edgecore is just a marketing name/sub-brand for the company Accton.

https://www.computextaipei.com.tw/en/index.html



On Sat, Nov 25, 2023 at 2:32 PM Aled Morris via NANOG 
wrote:

> I don't think IP Infustion makes hardware  - their OCNOS software runs on
> many third-party white-box platforms from the likes of EdgeCore and
> UfiSpace.
>
> There may well be a device that suits the OP's requirements amongst the
> supported hardware list.
>
> I refer you to this handy table:
>
> https://www.ipinfusion.com/documentation/ocnos-hardware-compatibility-list/
>
> Aled
>
> On Fri, 24 Nov 2023 at 16:33, Tom Mitchell 
> wrote:
>
>> I don't know about specific SKUs, but IP Infusion make a very popular set
>> of L2 switches.
>>
>>
>> On Wed, Nov 22, 2023 at 8:42 PM Ross Tajvar  wrote:
>>
>>> I'm evaluating CPEs for one of my clients, a regional ISP. Currently,
>>> we're terminating the customer's service (L3) on our upstream equipment and
>>> extending it over our own fiber to the customer's premise, where it lands
>>> in a Juniper EX2200 or EX2300.
>>>
>>> At a previous job, I used Accedian's ANTs on the customer prem side. I
>>> like the ANT because it has a small footprint with only 2 ports, it's
>>> passively cooled, it's very simple to operate, it's controlled centrally,
>>> etc. Unfortunately, when I reached out to Accedian, they insisted that the
>>> controller (which is required) started at $30k, which is a non-starter for
>>> us.
>>>
>>> I'm not aware of any other products like this. Does anyone have a
>>> recommendation for a simple L2* device to deploy to customer premises? Not
>>> necessarily the exact same thing, but something similarly-featured would be
>>> ideal.
>>>
>>> *I'm not sure if the ANT is exactly "layer 2", but I don't know what
>>> else to call it.
>>>
>>

Incident with AMS-IX drops 7.5 Tbps of traffic

[Eric Kuhnke]

https://www.ams-ix.net/ams/documentation/total-stats

https://www.ams-ix.net/ams/outage-on-amsterdam-peering-platform

Re: .US Harbors Prolific Malicious Link Shortening Service

[Eric Kuhnke]

I've seen a US based ISP do its internal management network reverse DNS
using '.us' as a suffix, where the hierarchy is like POP name, then
city/airport code, then state (eg: CA, NJ, FL), then .us for geographical
location of equipment in USA.

The .us domain in question was owned by the same organization but with only
a stub zone file published on public facing authoritatiev NS, with the
internal zonefile not available to the public.


On Mon, Nov 6, 2023 at 7:35 AM Jay R. Ashworth  wrote:

> - Original Message -
> > From: "Seth Mattinen via NANOG" 
>
> > On 11/2/23 1:30 PM, goemon--- via NANOG wrote:
> >> Are there any legitimate services running solely on .us domain names?
> >
> > Yes.
>
> Though not -- by several orders of magnitude -- nearly as many as there
> should
> be... but let's not get me started on that.
>
> Cheers,
> -- jr 'RFC1480' a
> --
> Jay R. Ashworth  Baylink
> j...@baylink.com
> Designer The Things I Think   RFC
> 2100
> Ashworth & Associates   http://www.bcp38.info  2000 Land
> Rover DII
> St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647
> 1274
>

Re: .US Harbors Prolific Malicious Link Shortening Service

[Eric Kuhnke]

Not specific to .US really

Pretty much every new gTLD that can be registered on "promotional" first
year prices below .com/.net/.org harbors a large than usual proportion of
phishing domains and suspicious things, because one of the sole operational
criteria for phishers registering disposable domains that might have useful
lives of only hours or a few days, in bulk, is the cost per unit.


".us" is in much the same situation because I am seeing promotional prices
of $4.50 to $5 per domain for the first year.





On Thu, Nov 2, 2023 at 1:31 PM goemon--- via NANOG  wrote:

>
> https://krebsonsecurity.com/2023/10/us-harbors-prolific-malicious-link-shortening-service/
>
> "The NTIA recently published a proposal that would allow registrars to
> redact all registrant data from WHOIS registration records for .US
> domains. A broad array of industry groups have filed comments opposing the
> proposed changes, saying they threaten to remove the last vestiges of
> accountability for a top-level domain that is already overrun with
> cybercrime activity."
>
> What hope is there when registrars are actively aiding and abeting
> criminal enterprises?
>
> Are there any legitimate services running solely on .us domain names?
>
> -Dan
>

Re: OSP Management

[Eric Kuhnke]

On that topic, I find it interesting to see how different medium/regional
scale ISPs have developed their own in-house GIS systems, once they reach
the size and scale where one FTE staff position to run GIS systems/database
backend is a necessity.

There is a great deal that can be done with QGIS and entirely GPL/BSD
licensed software, if your GIS person has a background in this sort of
thing.

Privately hosting a intranet-based tile-server for openstreetmap data and
overlaying your own network on top of it is not extremely difficult.



On Tue, Oct 31, 2023 at 6:27 AM michael brooks - ESC <
michael.bro...@adams12.org> wrote:

> On that note, what do you all use for managing OSP? We have been
> attempting to stand up PatchManager for quite some time, and find it a good
> product, but the billions of options can be overwhelming
>
>
>
>
> michael brooks
> Sr. Network Engineer
> Adams 12 Five Star Schools
> michael.bro...@adams12.org
> 
> "flying is learning how to throw yourself at the ground and miss"
>
>
>
> On Fri, Oct 27, 2023 at 5:54 AM Mike Hammett  wrote:
>
>>  Always fun managing OSP.
>>
>>
>>
>> -
>> Mike Hammett
>> Intelligent Computing Solutions
>> http://www.ics-il.com
>> 
>>
>> Midwest-IX
>> http://www.midwest-ix.com
>> 
>>
>>
> This is a staff email account managed by Adams 12 Five Star Schools.  This
> email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify the sender.

Re: [EXTERNAL] Re: Charter DNS servers returning malware filtered IP addresses

[Eric Kuhnke]

When you have a sufficiently large mass of non-technical end users,
inevitably some percentage of them will end up doing something like
enabling WAN-interface-facing remote admin access,which then gets pwned and
turned into a botnet. It's a real problem at scale. Compromised CPE routers
in addition to people visiting virus/trojan laden webservers and infecting
their endpoint devices.

good example:

https://www.fortinet.com/blog/threat-research/condi-ddos-botnet-spreads-via-tp-links-cve-2023-1389



On Fri, Oct 27, 2023 at 3:37 PM John Levine  wrote:

> It appears that Bryan Fields  said:
> >-=-=-=-=-=-
> >-=-=-=-=-=-
> >On 10/27/23 7:49 AM, John Levine wrote:
> >> But for obvious good reasons,
> >> the vast majority of their customers don't
> >
> >I'd argue that as a service provider deliberately messing with DNS is an
> >obvious bad thing.  They're there to deliver packets.
>
> For a network feeding a data center, sure. For a network like
> Charter's which is feeding unsophisticated nontechnical users, they
> need all the messing they can get.
>
> If you're one of the small minority of retail users that knows enough
> about the technology to pick your own resolver, go ahead.  But it's
> a reasonable default to keep malware out of Grandma's iPad.
>
> R's,
> John
>

Re: 165 Halsey recurring power issues

[Eric Kuhnke]

At which point one starts looking at the risk factors, if your whole
facility is "redundant", is the power feed coming in from two
geographically diverse substations, via diverse duct banks, into diverse
entry vaults, and diverse risers?

Doesn't eliminate the possibility of the entire building having some
catastrophic emergency, but if you really need to use a singular specific
geographic facility, can reduce the risk

The giant new electrical vault built under 6th Ave in Seattle in front of
the Westin Building back in 2016/2017 is an example of such diversity.



On Mon, Oct 23, 2023 at 7:08 PM Sean Donelan  wrote:

> On Mon, 23 Oct 2023, James Jun wrote:
> > "2N" generally means you're connected to completely different UPS
> system/complex and corresponding distribution systems for each of your
> circuit.  This is ideal configuration for most critical loads.
>
> If you are in a single facility, even one with 2N+2 backups, redundancy,
> diversity, etc., it still has shared fate.  Clouds with regions and zones
> on campuses in Eastern Virginia seem to come up with new and exciting ways
> to fail :-)
>
> https://en.wikipedia.org/wiki/Chaos_engineering
>

Re: 165 Halsey recurring power issues

[Eric Kuhnke]

I didn't say that I have sympathy for it but that unfortunately this is
considered acceptable practice within many low-budget "hosting" companies
and probably has been for 15 years. It's a known risk when you're buying a
$50/month "server". Same general category of problem as the OVH datacenter
that caught on fire in France a while back. Anything like that which
becomes a race to the bottom in pricing for product MRC will have
unacceptable corners cut.

I would highly encourage anyone who takes seriously hosting their own stuff
to really know/understand the full infrastructure "underneath" your server
in terms of power and cooling redundancy.

On Mon, Oct 23, 2023 at 4:38 PM William Herrin  wrote:

> On Mon, Oct 23, 2023 at 3:56 PM Eric Kuhnke  wrote:
> > Bulk/high-volume hosting companies, dedicated server companies/small
> > rack unit count colocation operate on very thin margins. Unless a
> > customer is paying a LOT more per month they're not economically
> > going to be connected to true diverse A/B power.
>
> Zero sympathy for anyone who advertises A/B power and doesn't at least
> have them connected to different UPSs. Don't care how big you are;
> don't advertise fake reliability. I don't need "six nines" to make
> effective use of your service but if you lie to me, we're done.
>
> Regards,
> Bill Herrin
>
>
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
>

Re: 165 Halsey recurring power issues

[Eric Kuhnke]

Bulk/high-volume hosting companies, dedicated server companies/small rack
unit count colocation operate on very thin margins. Unless a customer is
paying a LOT more per month they're not economically going to be connected
to true diverse A/B power.

In this case their use of the incorrectly-described A/B was probably
exclusively to handle the (not extremely rare) instances of rackmount
server power supply failures, to give each 1U or 2U size machine, or rack
of blades, two live power supplies with live power feeds. Nothing more
complicated than that.

On Mon, Oct 23, 2023 at 3:34 PM Aaron Wendel 
wrote:

> I toured The Planet years ago in Dallas and was told by the sales rep
> that A+B power was two circuits from the same PDU. :)
>
> I consider A+B power to be two distinct feeds, separate utility
> entrances, separate generators, separate UPS', PDU's, etc.  Past that I
> consider things like firewall separation, rated chases and such to be
> customer specific requirements.
>
> Aaron
>
> On 10/23/2023 9:38 AM, Babak Pasdar wrote:
> > Hello,
> >
> > I wanted to get some feedback as to what is considered standard A/B
> > power setup when data centers sell redundant power.  It has always
> > been my understanding that A/B power means individually unique and
> > preferably alternate path connections to disparate UPS units.
> >
> > A few months ago, 165 Halsey took us down for several hours. They
> > claimed that a UPS failed causing this issue.  Our natural reaction
> > was that we have A/B redundant power so a failed UPS on the A circuit
> > should not take down the cabinet. Joe the facility manager claimed
> > that industry standard A/B power means two circuits to the same UPS,
> > which makes no sense to me.
> >
> > They committed to move us to A/B power with redundant circuits to
> > disparate UPS units.  However, we had a multi-hour outage again in
> > that site this weekend. At first glance it seems to be the same problem.
> >
> > We have checked with all of our other data center providers who have
> > confirmed A/B power is in fact individually unique connections to
> > disparate UPS units. 165 Halsey's definition of what constitutes
> > redundant power seems unique. Why would anyone pay extra for a second
> > connection to the same UPS?  However, I wanted to get feedback to see
> > if I am taking crazy pills here 🙂
> >
> > None-the-less, we have lost all confidence in this facility.
> >
> > Best Regards,
> >
> > Babak
>
>

Re: ARIN election statistics, eligible-to-vote ASNs/Org IDs vs. number of votes cast

[Eric Kuhnke]

Thank you John!  I suppose the impetus behind my original question was to
encourage everyone reading this thread to examine the slate of candidates
and vote.

If I'm reading this right it appears that approximately 8 percent of
eligible voters cast a vote for the 2020 Board of Trustees election.

I've been going through the periodic ARIN election related emails and
expect to put some more time into it this weekend.

On Thu, Oct 19, 2023 at 9:08 PM John Curran  wrote:

>
> On Oct 19, 2023, at 5:25 PM, Eric Kuhnke  wrote:
>
> Does anyone have general statistics on:
>
> a) Number of eligible voting org IDs
>
> b) Percentage of eligible voting org IDs which actually cast ballots in
> previous ARIN elections
>
>
> That’s an interesting question to ask over here on nanog’s mailing list,
> but anyway here goes -
>
> ARIN 2022 Election Results -
> https://www.arin.net/announcements/20221031_results/
> ARIN 2021 Election Results -
> https://www.arin.net/announcements/2027_election/
> ARIN 2020 Election Results -
> https://www.arin.net/announcements/20201103_election/
>
>
> Each election result posting contains a summary at the bottom that
> includes metrics you seek - For example -
> ===
>
> 2020 Voter Statistics
>
>
>- 6,689 ARIN Members as of 8 September 2020
>   - 5,684 ARIN eligible Voting Organizations* as of 8 September 2020
>   - ARIN Board of Trustees election: 490 voters on behalf of 603
>   unique ARIN Member organizations cast a ballot in the ARIN Board of
>   Trustees election
>   - ARIN Advisory Council election: 485 voters on behalf of 595
>   unique ARIN Member organizations cast a ballot in the ARIN Advisory 
> Council
>   election
>
> **ARIN Member in Good Standing with a properly registered Voting Contact
> linked to an ARIN Online account as of 8 September 2020.*
>
> ===
>
>
> Best wishes,
> /John
>
> John Curran
> President and CEO
> American Registry for Internet Numbers
>
>
>
>

ARIN election statistics, eligible-to-vote ASNs/Org IDs vs. number of votes cast

[Eric Kuhnke]

Does anyone have general statistics on:

a) Number of eligible voting org IDs

b) Percentage of eligible voting org IDs which actually cast ballots in
previous ARIN elections

Re: ARIN whois contact abuse from ipv4depot aka Silicon Desert International Inc

[Eric Kuhnke]

To clarify, the original post from myself is more ARIN related and scraping
of ARIN data. The incoming cold contacts from the ipv4-broker-spammer came
to ARIN POCs for an ASN with presence only in the USA.



On Fri, Oct 13, 2023 at 8:23 AM t...@pelican.org  wrote:

> On Friday, 13 October, 2023 16:04, "Laura Smith via NANOG" <
> nanog@nanog.org> said:
>
> > RIPE could do the same.  And some might argue that it is easier for RIPE
> because
> > all we are asking is for a valid abuse contact, so its not like Nominet
> who have
> > to verify e.g. registrant company ID numbers.
>
> They do.  In previous lives, I've regularly been on the receiving end of
> assorted audit requests from RIPE, some of which are to do with contact
> details in the DB (particularly when they find unreachable ones), and some
> of which are confirming that number resources are still in use by the
> organisation and for the purpose for which they were issued.
>
> I think the original complaint was that RIPE don't act (or less so than
> ARIN) to block or otherwise deal with people who are mining the DB for
> contacts, despite that being an incentive to put "real" data in the DB -
> not than that they don't push for accurate data in the DB.
>
> Thanks,
> Tim.
>
>
>

ARIN whois contact abuse from ipv4depot aka Silicon Desert International Inc

[Eric Kuhnke]

Is anyone else receiving spam from this organization? Based on the contents
of the cold solicitations they are sending us, and the addresses being sent
to, they have scraped ARIN WHOIS data for noc and abuse POC contact info
and recent ipv4 block transfers.

It's trivially easy to block their entire domain at the mail server level,
of course...

Re: cogent spamming directly from ARIN records?

[Eric Kuhnke]

Based on my personal experience of getting onto the contact list of an
extremely persistent Cogent sales person, mostly, I am morbidly curious
what their CRM system looks like for cold and stale leads, and how often
these sets of non-responsive leads get passed on to new junior salespeople.
And exactly how many of those sales people there are and what
policies/management structure they work under.

It took a fair amount of effort and many strongly worded responses on my
part to eventually get my personal cellular phone number removed from their
CRM system (or at least marked as a do-not-contact).

On Mon, Oct 2, 2023 at 6:52 PM Mel Beckman  wrote:

> This morning I received an email from someone at Cogent asking about an
> ASN I administer. They didn’t give any details, but I assumed it might be
> related to some kind of network transport issue. I replied cordially,
> asking them what they needed. The person then replied with a blatant spam,
> advertising Cogent IP services, in violation of the U.S. CAN-SPAM Act’s
> prohibition against deceptive UCE.
>
> I believe they got the contact information from ARIN, because the ARIN
> technical POC is the only place where my name and the ASN are connected. I
> believe this is a violation of Cogent’s contract with ARIN. Does anybody
> know how I can effectively report this to ARIN? If we can’t even police
> infrastructure providers for spamming, LIOAWKI.
>
>  -mel beckman

Re: what is acceptible jitter for voip and videoconferencing?

[Eric Kuhnke]

Artifacts in audio are a product of packet loss or jitter resulting in
codec issues issues leading to human subject perceptible audio anomalies,
not so much latency by itself. Two way voice is remarkably NOT terrible on
a 495ms RTT satellite based two-way geostationary connection as long as
there is little or no packet loss.

On Thu, Sep 21, 2023 at 12:47 PM Tom Beecher  wrote:

> My understanding has always been that 30ms was set based on human
> perceptibility. 30ms was the average point at which the average person
> could start to detect artifacts in the audio.
>
> On Tue, Sep 19, 2023 at 8:13 PM Dave Taht  wrote:
>
>> Dear nanog-ers:
>>
>> I go back many, many years as to baseline numbers for managing voip
>> networks, including things like CISCO LLQ, diffserv, fqm prioritizing
>> vlans, and running
>> voip networks entirely separately... I worked on codecs, such as oslec,
>> and early sip stacks, but that was over 20 years ago.
>>
>> The thing is, I have been unable to find much research (as yet) as to why
>> my number exists. Over here I am taking a poll as to what number is most
>> correct (10ms, 30ms, 100ms, 200ms),
>>
>> https://www.linkedin.com/feed/update/urn:li:ugcPost:7110029608753713152/
>>
>> but I am even more interested in finding cites to support various
>> viewpoints, including mine, and learning how slas are met to deliver it.
>>
>> --
>> Oct 30:
>> https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
>> Dave Täht CSO, LibreQos
>>
>

Re: AFRINIC placed in receivership

[Eric Kuhnke]

I'm not quite sure that we agree on the meaning of "legitimate application"
when a HK based corporate entity is using and claiming permanent rights to
AFRINIC IP space, primarily for ISP operations in east asia.

There have been multiple well documented instances of AFRINIC insiders with
privileged access shoveling IP space out the back door by less than
legitimate means. For a number of different suspicious recipients.

Undoubtedly this is part of what contributed to its board members and
management fleeing the organization in the face of litigation and
investigations.

The fact that these organizations that received IP space by less than
honest means are now suing AFRINIC into financial oblivion honestly does
not help the situation.



On Fri, Sep 15, 2023 at 5:04 PM Delong.com  wrote:

> Noe… You are conflating two completely different cases, sir.
>
> CI submitted legitimate applications and their addresses were issued prior
> to Ernest’s activities.
>
> You’re mixing Lu Heng up with Elad Cohen.
>
> Owen
>
>
> On Sep 15, 2023, at 16:32, Eric Kuhnke  wrote:
>
>
> https://www.devdiscourse.com/article/international/1813989-the-strange-case-of-africas-stolen-ip-addresses
>
>
> https://www.google.com/search?client=firefox-b-d&q=Ernest+Byaruhanga+afrinic
>
> On Fri, Sep 15, 2023 at 4:30 PM Eric Kuhnke  wrote:
>
>> > AFRINIC legitimately issued those (closer to 6M) IP addresses to Cloud
>> Innovation based on justifications submitted. AFRINIC then attempted, using
>> claims that usage out of region is not permitted by the bylaws
>> (It is not prohibited by the bylaws, feel free to read them yourself), to
>> reclaim those addresses.
>>
>> This is not what happened. AFRINIC issued those IP addresses to Cloud
>> Innovations based on fundamental misrepresentations by the applicant and
>> internal fraudulent activity conducted by a single employee within AFRINIC.
>>
>>
>>
>> On Fri, Sep 15, 2023 at 4:17 PM Delong.com  wrote:
>>
>>>
>>>
>>> On Sep 15, 2023, at 15:05, Eric Kuhnke  wrote:
>>>
>>> A much better explanation of the situation can be found at:
>>>
>>> https://www.theregister.com/2023/07/03/nrs_afrinic_review/
>>>
>>> I also recommend that everyone who is not yet familiar with the issue
>>> google Lu Heng and Cloud Innovations, the Hong Kong based corporate entity
>>> in question which caused this.
>>>
>>>
>>> Fair suggestion, but I wouldn’t say it’s fair to say Lu Heng or CI
>>> caused this. I’d say that AFRINIC’s
>>> leadership at the time had an at least equal role in creating the
>>> problems and in failing to address
>>> Them in a timely manner.
>>>
>>> CI didn’t sue AFRINIC for nothing. AFRINIC, in violation of the actual
>>> text of their bylaws attempted
>>> to revoke CI space and created major disruptions to a number of networks
>>> in the process. Had CI
>>> not received the injunctions they got from the courts, likely the
>>> disruption would have been much
>>> worse and caused some pretty wide-spread outages.
>>>
>>>
>>>
>>> https://www.google.com/search?client=firefox-b-d&q=lu+heng+cloud+innovation
>>>
>>> The short version of this is that a HK based corporate entity claims it
>>> is the legitimate "owner" of 7 million AFRINIC IPs.
>>>
>>>
>>> AFRINIC legitimately issued those (closer to 6M) IP addresses to Cloud
>>> Innovation based on justifications submitted. AFRINIC then attempted, using
>>> claims that usage out of region is not permitted by the bylaws
>>> (It is not prohibited by the bylaws, feel free to read them yourself),
>>> to reclaim those addresses.
>>>
>>> AFRINIC whois and the courts have confirmed that Cloud Innovation is the
>>> rightful registrant of those
>>> addresses at the time and as of now. Until a court rules otherwise
>>> (which is very unlikely at this point),
>>> they don’t “own” the addresses, but they do “own” the rights to those
>>> registrations in the AFRINIC
>>> database.
>>>
>>> (Nobody “owns” any integers… Everyone remains equally free to use the
>>> number 5 as much as they want.)
>>>
>>> Owen
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Sep 14, 2023 at 6:09 AM Bryan Fields 
>>> wrote:
>>>
>>>> On 9/13/23 9:27 PM, Bryan Fields wrote:
>>>> > I think this qualifies as potentially operational.
>>>> >
>>>> > Afrinic placed in receivership, board elections to be held in six
>>>> months:
>>>> > https://archive.ph/jOFE4
>>>>
>>>> Looks like archive.ph is having problems.  This is the original
>>>> article.
>>>>
>>>> >
>>>> https://www.capacitymedia.com/article/2c6pnx4ymt7sd5c493wg0/news/exclusive-afrinic-placed-in-receivership-board-elections-to-be-held-in-six-months
>>>> --
>>>> Bryan Fields
>>>>
>>>> 727-409-1194 - Voice
>>>> http://bryanfields.net
>>>>
>>>
>>>
>

Re: AFRINIC placed in receivership

[Eric Kuhnke]

https://www.devdiscourse.com/article/international/1813989-the-strange-case-of-africas-stolen-ip-addresses

https://www.google.com/search?client=firefox-b-d&q=Ernest+Byaruhanga+afrinic

On Fri, Sep 15, 2023 at 4:30 PM Eric Kuhnke  wrote:

> > AFRINIC legitimately issued those (closer to 6M) IP addresses to Cloud
> Innovation based on justifications submitted. AFRINIC then attempted, using
> claims that usage out of region is not permitted by the bylaws
> (It is not prohibited by the bylaws, feel free to read them yourself), to
> reclaim those addresses.
>
> This is not what happened. AFRINIC issued those IP addresses to Cloud
> Innovations based on fundamental misrepresentations by the applicant and
> internal fraudulent activity conducted by a single employee within AFRINIC.
>
>
>
> On Fri, Sep 15, 2023 at 4:17 PM Delong.com  wrote:
>
>>
>>
>> On Sep 15, 2023, at 15:05, Eric Kuhnke  wrote:
>>
>> A much better explanation of the situation can be found at:
>>
>> https://www.theregister.com/2023/07/03/nrs_afrinic_review/
>>
>> I also recommend that everyone who is not yet familiar with the issue
>> google Lu Heng and Cloud Innovations, the Hong Kong based corporate entity
>> in question which caused this.
>>
>>
>> Fair suggestion, but I wouldn’t say it’s fair to say Lu Heng or CI caused
>> this. I’d say that AFRINIC’s
>> leadership at the time had an at least equal role in creating the
>> problems and in failing to address
>> Them in a timely manner.
>>
>> CI didn’t sue AFRINIC for nothing. AFRINIC, in violation of the actual
>> text of their bylaws attempted
>> to revoke CI space and created major disruptions to a number of networks
>> in the process. Had CI
>> not received the injunctions they got from the courts, likely the
>> disruption would have been much
>> worse and caused some pretty wide-spread outages.
>>
>>
>>
>> https://www.google.com/search?client=firefox-b-d&q=lu+heng+cloud+innovation
>>
>> The short version of this is that a HK based corporate entity claims it
>> is the legitimate "owner" of 7 million AFRINIC IPs.
>>
>>
>> AFRINIC legitimately issued those (closer to 6M) IP addresses to Cloud
>> Innovation based on justifications submitted. AFRINIC then attempted, using
>> claims that usage out of region is not permitted by the bylaws
>> (It is not prohibited by the bylaws, feel free to read them yourself), to
>> reclaim those addresses.
>>
>> AFRINIC whois and the courts have confirmed that Cloud Innovation is the
>> rightful registrant of those
>> addresses at the time and as of now. Until a court rules otherwise (which
>> is very unlikely at this point),
>> they don’t “own” the addresses, but they do “own” the rights to those
>> registrations in the AFRINIC
>> database.
>>
>> (Nobody “owns” any integers… Everyone remains equally free to use the
>> number 5 as much as they want.)
>>
>> Owen
>>
>>
>>
>>
>>
>>
>> On Thu, Sep 14, 2023 at 6:09 AM Bryan Fields 
>> wrote:
>>
>>> On 9/13/23 9:27 PM, Bryan Fields wrote:
>>> > I think this qualifies as potentially operational.
>>> >
>>> > Afrinic placed in receivership, board elections to be held in six
>>> months:
>>> > https://archive.ph/jOFE4
>>>
>>> Looks like archive.ph is having problems.  This is the original article.
>>>
>>> >
>>> https://www.capacitymedia.com/article/2c6pnx4ymt7sd5c493wg0/news/exclusive-afrinic-placed-in-receivership-board-elections-to-be-held-in-six-months
>>> --
>>> Bryan Fields
>>>
>>> 727-409-1194 - Voice
>>> http://bryanfields.net
>>>
>>
>>

Re: AFRINIC placed in receivership

[Eric Kuhnke]

> AFRINIC legitimately issued those (closer to 6M) IP addresses to Cloud
Innovation based on justifications submitted. AFRINIC then attempted, using
claims that usage out of region is not permitted by the bylaws
(It is not prohibited by the bylaws, feel free to read them yourself), to
reclaim those addresses.

This is not what happened. AFRINIC issued those IP addresses to Cloud
Innovations based on fundamental misrepresentations by the applicant and
internal fraudulent activity conducted by a single employee within AFRINIC.



On Fri, Sep 15, 2023 at 4:17 PM Delong.com  wrote:

>
>
> On Sep 15, 2023, at 15:05, Eric Kuhnke  wrote:
>
> A much better explanation of the situation can be found at:
>
> https://www.theregister.com/2023/07/03/nrs_afrinic_review/
>
> I also recommend that everyone who is not yet familiar with the issue
> google Lu Heng and Cloud Innovations, the Hong Kong based corporate entity
> in question which caused this.
>
>
> Fair suggestion, but I wouldn’t say it’s fair to say Lu Heng or CI caused
> this. I’d say that AFRINIC’s
> leadership at the time had an at least equal role in creating the problems
> and in failing to address
> Them in a timely manner.
>
> CI didn’t sue AFRINIC for nothing. AFRINIC, in violation of the actual
> text of their bylaws attempted
> to revoke CI space and created major disruptions to a number of networks
> in the process. Had CI
> not received the injunctions they got from the courts, likely the
> disruption would have been much
> worse and caused some pretty wide-spread outages.
>
>
> https://www.google.com/search?client=firefox-b-d&q=lu+heng+cloud+innovation
>
> The short version of this is that a HK based corporate entity claims it is
> the legitimate "owner" of 7 million AFRINIC IPs.
>
>
> AFRINIC legitimately issued those (closer to 6M) IP addresses to Cloud
> Innovation based on justifications submitted. AFRINIC then attempted, using
> claims that usage out of region is not permitted by the bylaws
> (It is not prohibited by the bylaws, feel free to read them yourself), to
> reclaim those addresses.
>
> AFRINIC whois and the courts have confirmed that Cloud Innovation is the
> rightful registrant of those
> addresses at the time and as of now. Until a court rules otherwise (which
> is very unlikely at this point),
> they don’t “own” the addresses, but they do “own” the rights to those
> registrations in the AFRINIC
> database.
>
> (Nobody “owns” any integers… Everyone remains equally free to use the
> number 5 as much as they want.)
>
> Owen
>
>
>
>
>
>
> On Thu, Sep 14, 2023 at 6:09 AM Bryan Fields 
> wrote:
>
>> On 9/13/23 9:27 PM, Bryan Fields wrote:
>> > I think this qualifies as potentially operational.
>> >
>> > Afrinic placed in receivership, board elections to be held in six
>> months:
>> > https://archive.ph/jOFE4
>>
>> Looks like archive.ph is having problems.  This is the original article.
>>
>> >
>> https://www.capacitymedia.com/article/2c6pnx4ymt7sd5c493wg0/news/exclusive-afrinic-placed-in-receivership-board-elections-to-be-held-in-six-months
>> --
>> Bryan Fields
>>
>> 727-409-1194 - Voice
>> http://bryanfields.net
>>
>
>

Re: AFRINIC placed in receivership

[Eric Kuhnke]

A much better explanation of the situation can be found at:

https://www.theregister.com/2023/07/03/nrs_afrinic_review/

I also recommend that everyone who is not yet familiar with the issue
google Lu Heng and Cloud Innovations, the Hong Kong based corporate entity
in question which caused this.

https://www.google.com/search?client=firefox-b-d&q=lu+heng+cloud+innovation

The short version of this is that a HK based corporate entity claims it is
the legitimate "owner" of 7 million AFRINIC IPs.



On Thu, Sep 14, 2023 at 6:09 AM Bryan Fields  wrote:

> On 9/13/23 9:27 PM, Bryan Fields wrote:
> > I think this qualifies as potentially operational.
> >
> > Afrinic placed in receivership, board elections to be held in six months:
> > https://archive.ph/jOFE4
>
> Looks like archive.ph is having problems.  This is the original article.
>
> >
> https://www.capacitymedia.com/article/2c6pnx4ymt7sd5c493wg0/news/exclusive-afrinic-placed-in-receivership-board-elections-to-be-held-in-six-months
> --
> Bryan Fields
>
> 727-409-1194 - Voice
> http://bryanfields.net
>

Looking for contact at AS6428 aka River City Internet Group / Hostirian / Primary.net

[Eric Kuhnke]

You are announcing IP space that doesn't belong to you, for which you are
not in possession of an LOA (or any IRR entry/etc) and the phone numbers in
your ARIN whois entries are disconnected.

First tier customer service person at the one functioning phone number has
no pathway to escalate.

AS6428 / AS10510 (same company)

Please contact me off-list as soon as possible.

Re: Lossy cogent p2p experiences?

[Eric Kuhnke]

Cogent has asked many people NOT to purchase their ethernet private circuit
point to point service unless they can guarantee that you won't move any
single flow of greater than 2 Gbps. This works fine as long as the service
is used mostly for mixed IP traffic like a bunch of randomly mixed
customers together.

What you are trying to do is probably against the guidelines their
engineering group has given them for what they can sell now.

This is a known weird limitation with Cogent's private circuit service.

The best working theory that several people I know in the neteng community
have come up with is because Cogent does not want to adversely impact all
other customers on their router in some sites, where the site's upstreams
and links to neighboring POPs are implemented as something like 4 x 10
Gbps. In places where they have not upgraded that specific router to a full
100 Gbps upstream. Moving large flows >2Gbps could result in flat topping a
traffic chart on just 1 of those 10Gbps circuits.



On Thu, Aug 31, 2023 at 10:04 AM David Hubbard <
dhubb...@dino.hostasaurus.com> wrote:

> Hi all, curious if anyone who has used Cogent as a point to point provider
> has gone through packet loss issues with them and were able to successfully
> resolve?  I’ve got a non-rate-limited 10gig circuit between two geographic
> locations that have about 52ms of latency.  Mine is set up to support both
> jumbo frames and vlan tagging.  I do know Cogent packetizes these circuits,
> so they’re not like waves, and that the expected single session TCP
> performance may be limited to a few gbit/sec, but I should otherwise be
> able to fully utilize the circuit given enough flows.
>
>
>
> Circuit went live earlier this year, had zero issues with it.  Testing
> with common tools like iperf would allow several gbit/sec of TCP traffic
> using single flows, even without an optimized TCP stack.  Using parallel
> flows or UDP we could easily get close to wire speed.  Starting about ten
> weeks ago we had a significant slowdown, to even complete failure, of
> bursty data replication tasks between equipment that was using this
> circuit.  Rounds of testing demonstrate that new flows often experience
> significant initial packet loss of several thousand packets, and will then
> have ongoing lesser packet loss every five to ten seconds after that.
> There are times we can’t do better than 50 Mbit/sec, but it’s rare to
> achieve gigabit most of the time unless we do a bunch of streams with a lot
> of tuning.  UDP we also see the loss, but can still push many gigabits
> through with one sender, or wire speed with several nodes.
>
>
>
> For equipment which doesn’t use a tunable TCP stack, such as storage
> arrays or vmware, the retransmits completely ruin performance or may result
> in ongoing failure we can’t overcome.
>
>
>
> Cogent support has been about as bad as you can get.  Everything is great,
> clean your fiber, iperf isn’t a good test, install a physical loop oh wait
> we don’t want that so go pull it back off, new updates come at three to
> seven day intervals, etc.  If the performance had never been good to begin
> with I’d have just attributed this to their circuits, but since it worked
> until late June, I know something has changed.  I’m hoping someone else has
> run into this and maybe knows of some hints I could give them to
> investigate.  To me it sounds like there’s a rate limiter / policer defined
> somewhere in the circuit, or an overloaded interface/device we’re forced to
> traverse, but they assure me this is not the case and claim to have
> destroyed and rebuilt the logical circuit.
>
>
>
> Thanks!
>

Re: MX204 Virtual Chassis Setup

[Eric Kuhnke]

Look at the population of 100G ports at the SIX in Seattle as well. I think
there's a total of maybe four 40G members out of hundreds. 100G really is
the new 10.

On Sun, Aug 27, 2023, 10:56 PM Daniel Marks via NANOG 
wrote:

> (Enterprise AS for context)
>
> This hasn’t been my experience in the US, however we mostly deal in tier 2
> markets (I.e. Detroit, Miami, Dallas, etc…) and we have plenty of 40G
> private interconnects. I don’t doubt 40G is going away, I’ve just never had
> trouble using it around here.
>
> The only time we’ve been asked to run something other than 40G was because
> we like to run our ports very hot (latency insensitive traffic) and some
> networks do not tolerate consistently high utilization of their ports.
>
> Different story in Japan, it’s 100G+ or nothing. You just have to find
> someone willing to peer with you in the first place…
>
> Sent from my iPhone
>
> On Aug 27, 2023, at 23:43, Mark Tinka  wrote:
>
> 
>
> On 8/28/23 03:05, Mike Hammett wrote:
>
> Well, or they simply found a potential deal on hardware that came with 40
> gig ports. 40 gigs is still a lot of bits to a lot of people.
>
>
> For internal use, sure.
>
> But when connecting to another AS, the chances of them supporting 40Gbps
> in one or more places is inconsistent to slim.
>
> Exchange points may be an exception.
>
> Mark.
>
>

Re: MX204 Virtual Chassis Setup

[Eric Kuhnke]

I sincerely doubt there is much demand for *new* 40G these days.

Look at the population of 40G members on major IXes.

People have either one 10G, 2 x 10G, or 100G.

40G was a dead-end 9 years ago and much so more now.



On Wed, Aug 23, 2023 at 9:38 AM Aaron Gould  wrote:

> some of these port capabilities are weird to me.  like on the
> ACX7100-48L you can do 4x100 or 8x50, but ONLY one 40g ?!
>
> me@7100> show chassis pic pic-slot 0 fpc-slot 0 | find 400
>48 0   1x400G 1x100G 1x40G 4x100G 2x100G 8x50G 2x50G 4x25G
> 4x10G 3x100G
>49 0   1x400G 1x100G 1x40G 4x100G 2x100G 8x50G 2x50G 4x25G
> 4x10G 3x100G
>50 0   1x400G 1x100G 1x40G 4x100G 2x100G 8x50G 2x50G 4x25G
> 4x10G 3x100G
>51 0   1x400G 1x100G 1x40G 4x100G 2x100G 8x50G 2x50G 4x25G
> 4x10G 3x100G
>52 0   1x400G 1x100G 1x40G 4x100G 2x100G 8x50G 2x50G 4x25G
> 4x10G 3x100G
>53 0   1x400G 1x100G 1x40G 4x100G 2x100G 8x50G 2x50G 4x25G
> 4x10G 3x100G
>54 NA  1x10G
>
>
>
>
> On 8/23/2023 11:29 AM, t...@pelican.org wrote:
> > On Wednesday, 23 August, 2023 16:33, "Mark Tinka" 
> said:
> >
> > [faceplate oversubscription]
> >
> >> On the new ACX line, yes.
> > Not Trio, and different PLM :)
> >
> >> We don't mess around with any other MX products, so not sure (although
> >> we are still yet to deploy the MPC10E's and the MX304).
> > MX304 (well, strictly LMIC16) has the same restriction, and a need for
> another entry in the magic port checker (
> https://apps.juniper.net/home/port-checker/index.html) for restrictions
> beyond "SUM(port-speeds) <= 1.6T".
> >
> > They make sense once you've looked at the block diagram for the thing
> and followed the lines, but things like "4x10G breakout can only go in
> odd-numbered ports, and you have to leave the corresponding next-lowest
> even-numbered port empty" are not instantly obvious.
> >
> > Thanks,
> > Tim.
> >
> >
> --
> -Aaron
>
>

Re: AKAMAI, Re: Apple blocking all AS29852 iCloud traffic, residential gigabit last mile provider in NYC.

[Eric Kuhnke]

We are indeed doing so. As a symmetric gigabit and above last mile provider
(we have 2.5, 5 and 10 Gbps to the home customers in Manhattan) the very
rare instances where a customer becomes compromised or a malicious traffic
source are worse than the usual.

>From a network topology perspective, and for flows, AS29852 looks a lot
like a hosting company/colo company in NYC with high throughput outbound
endpoints. But we are not, we're a condo and apartment focused last mile
provider that just happens to provide ridiculously fast speed to the
customers. In terms of abuse we have the usual ongoing issues to deal with
that are faced by any provider that operates free amenity wifi in public
spaces (roof terraces, lobbies, social rooms etc) in large condo
buildings.  We have some sites that are 600 suites in one building.

We just got the following from Akamai. This present issue may have been
exacerbated by something going on inside their DNS operations.

===

Thanks for sharing the reference error, it belongs to Thu, 17 Aug 2023
17:42:04 GMT.
The traffic was not denied here due to any security rules but there were
DNS connection issues with a set of Akamai servers in North America
yesterday and the issue was mitigated.

If you are still getting reports of any issues, please share with us.

This was a widespread incident where end-users faced connection timeouts
accessing Akamai's customer sites in North America. We can confirm that the
issue is now resolved as of 19:50 UTC on August 17, 2023 and the service
has resumed normal operations.
https://www.akamaistatus.com/incidents/jfjr19vjlb3l


On Fri, Aug 18, 2023 at 12:38 AM Dobbins, Roland <
roland.dobb...@netscout.com> wrote:

>
>
> On 18 Aug 2023, at 08:28, Eric Kuhnke  wrote:
>
> Additionally this appears to have a strong correlation with everything
> that is hosted by Akamai Edge. Akamai, we are a fairly mundane last mile
> operator…
>
>
> It might be a good idea to analyze your outbound traffic in order to
> determine if you/your customers have DDoS-capable bots and/or abusable
> reflectors/amplifiers on your/their networks which are being leveraged in
> attacks.
>

AKAMAI, Re: Apple blocking all AS29852 iCloud traffic, residential gigabit last mile provider in NYC.

[Eric Kuhnke]

Additionally this appears to have a strong correlation with everything that
is hosted by Akamai Edge. Akamai, we are a fairly mundane last mile
operator...

On Thu, Aug 17, 2023, 4:58 PM Eric Kuhnke  wrote:

> I am directly in contact with the right people and team now.
>
> On Thu, Aug 17, 2023, 3:53 PM Eric Kuhnke  wrote:
>
>> We have just seen a complete cut off of iCloud and Apple TV traffic and
>> functionality at AS29852.
>>
>> AS29852 (Honest) is a specialist in apartment and condominium building
>> symmetric gigabit and above residential last Mile access, based in the New
>> York city, Jersey City, and Connecticut region.
>>
>> All of the IP space that we announce to our peers and upstreams is used
>> for either residential last mile purposes, or small to medium size business
>> DIA last mile.
>>
>> A very high percentage of our customer base are avid paying iCloud users.
>>
>> If anybody at Apple is paying attention to the list, or can reach out to
>> me directly, I am happy to provide additional information.
>>
>>
>>
>>
>>

Re: Apple blocking all AS29852 iCloud traffic, residential gigabit last mile provider in NYC.

[Eric Kuhnke]

I am directly in contact with the right people and team now.

On Thu, Aug 17, 2023, 3:53 PM Eric Kuhnke  wrote:

> We have just seen a complete cut off of iCloud and Apple TV traffic and
> functionality at AS29852.
>
> AS29852 (Honest) is a specialist in apartment and condominium building
> symmetric gigabit and above residential last Mile access, based in the New
> York city, Jersey City, and Connecticut region.
>
> All of the IP space that we announce to our peers and upstreams is used
> for either residential last mile purposes, or small to medium size business
> DIA last mile.
>
> A very high percentage of our customer base are avid paying iCloud users.
>
> If anybody at Apple is paying attention to the list, or can reach out to
> me directly, I am happy to provide additional information.
>
>
>
>
>

Apple blocking all AS29852 iCloud traffic, residential gigabit last mile provider in NYC.

[Eric Kuhnke]

We have just seen a complete cut off of iCloud and Apple TV traffic and
functionality at AS29852.

AS29852 (Honest) is a specialist in apartment and condominium building
symmetric gigabit and above residential last Mile access, based in the New
York city, Jersey City, and Connecticut region.

All of the IP space that we announce to our peers and upstreams is used for
either residential last mile purposes, or small to medium size business DIA
last mile.

A very high percentage of our customer base are avid paying iCloud users.

If anybody at Apple is paying attention to the list, or can reach out to me
directly, I am happy to provide additional information.

Re: Hawaiian ILEC infrastructure and fire

[Eric Kuhnke]

The single road, or two road situation is extremely similar to what is
happening right now in some parts of canada, with massive forest fires in
the northwest territories, cutting off Yellowknife and rural communities.
If the fiber is built along the one road that exists, and that one road
gets overwhelmed by Forest fire, game over.

On Thu, Aug 17, 2023, 12:51 AM William Herrin  wrote:

> On Wed, Aug 16, 2023 at 6:43 PM scott via NANOG  wrote:
> > Last, it's an island and diverse paths are
> > short in number.
>
> To put it into perspective: there are exactly TWO roads that can get
> you from Lahaina back to Kahului and the airport. One of them is a
> narrow, cliff-hugging single lane road that is more or less paved.
>
> Though I am curious about the Paniolo cable landing in Lahaina. Did it
> survive? HICS and HIFN land in Kihei instead, right?
>
> Regards,
> Bill Herrin
>
>
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
>

Looking for Hulu geolocation and IP space block contact

[Eric Kuhnke]

I have a large set of residential last mile gigabit customers in the NYC/NJ
area where the /24 sized blocks for our CPE DHCP pools has just been
blocked by Hulu. Please contact me off list.

I am also trying to help Hulu here, because they're about to have several
thousand customers complaining, or taking up the time of their customer
service staff.

Re: Hawaiian ILEC infrastructure and fire

[Eric Kuhnke]

It's my understanding that the Hawaiian ILEC is now owned by Cincinnati
Bell, which is also a unique historical artifact, as it was its own
independent corporation/operating entity in the region of Cincinnati during
the era of the pre-1984 Bell system.

Somewhat like how GTE was independent in other places in the country.

https://en.wikipedia.org/wiki/Cincinnati_Bell

Some of the Hawaii ILEC structures I have seen photos of in other
non-fire-affected places and other islands have a resemblance to designs
that were built by BCTel, the ILEC in British Columbia, at the time when
GTE was a shareholder in BCTel.



On Wed, Aug 16, 2023 at 10:50 AM Jay Hennigan  wrote:

> On 8/16/23 09:32, Jay R. Ashworth wrote:
>
> > Well, it sounds like the historical Bell System attitude has transitioned
> > forwards to ... newer transport.  Good.
>
> Legacy GTE in this case, but agreed.
>
> > Best of luck to you all, out there.
>
> Indeed.
>
> --
> Jay Hennigan - j...@west.net
> Network Engineering - CCIE #7880
> 503 897-8550 - WB6RDV
>
>

Hawaiian ILEC infrastructure and fire

[Eric Kuhnke]

Recently saw an aerial video where an entire neighborhood in Laihana had
burned down *except* for the concrete block structure small ILEC CO.

Pictures I have seen of other ILEC sites in Hawaii closely resemble some
GTE sites in the Pacific Northwest (now Ziply), which makes sense with the
history of GTE in Hawaii.

Does anyone have some more detailed photos or examples of a telecom site
that's survived while everything else around it is burned up?

I'm looking to share this with some contacts in BC for rural telecom
purposes and disaster preparedness discussions.

Looking for a Telus cellular last mile facilities operations contact

[Eric Kuhnke]

I have observed a Telus cellular site shelter that's making a terrible, not
normal ventilation noise.

It's a 12+ foot length prefab assemble on site shelter located in the
basement parking garage of a 23 floor tower in downtown Vancouver. I know
what this POP's normal ventilation sounds like, having seen.and heard it in
operation for several years now, and this isn't healthy.

Based on the amount of sectors on the roof and ptp microwave links from
this site I would guess this is a more important than ordinary site, so if
Telus doesn't want to wait for it to overheat and die, contact me off list
for the street address of the building.

I have already tried spending about 45 minutes on the phone with Telus
customer service (I am not a customer) and this has been making the "I am a
dying ventilation blower" noise for two weeks now.

Re: Cogent Abuse - Bogus Propagation of ASN 36471

[Eric Kuhnke]

I might note for those who are unfamiliar with it, that the "Kratos" entity
is a major US defense contractor and manufacturer of advanced UAVs, so if
this issue is not addressed it has a high likelihood of getting attention
from some of the more clued-in folks in the federal government.

https://en.wikipedia.org/wiki/Kratos_XQ-58_Valkyrie


On Thu, Jul 20, 2023 at 7:31 AM 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: Suggestions for those attending NANOG 88 in Seattle

[Eric Kuhnke]

One observation on that, for those who find themselves in the area of the
Westin Building for ISP/telecom related work:

The Amazon HQ underground parking on 6th ave, with entrance literally
across the street from the Westin Building, is available for the public to
use. Entrance is on 6th ave between Virginia and Lenora. You don't need an
Amazon access badge/etc to use it, standard pay upon exit system.  I
believe it's marked on Google Maps as the "Amazon Doppler" garage.

It has slightly better prices than the Westin's own parking garage and the
vehicle spacing is not bad, I have parked full size SUVs in it without too
much trouble. Not that it's a good idea to leave bags or anything visible
in an unattended vehicle in downtown Seattle, but the garage also has
*slightly* better security than your average unstaffed parking garage
elsewhere in the city.


On Tue, Mar 28, 2023 at 12:14 PM William Herrin  wrote:

> Also, beware that downtown Seattle parking spaces are super-tight. If
> you rent a car, get a compact. Really.
>
> Regards,
> Bill Herrin
>
> On Tue, Mar 28, 2023 at 12:10 PM William Herrin  wrote:
> >
> > Some entertainment tips for those of you who plan to attend NANOG 88 in
> Seattle:
> >
> > 1. The Connections Museum is a must-see for telecom enthusiasts (which
> > I assume you are since you're attending a NANOG meeting). Six
> > different phone switches (some electromechanical) and a boatload of
> > other stuff taking up a floor and a half of a "central office"
> > building. In good working order. You can see and, to some extent,
> > touch. https://www.telcomhistory.org/connections-museum-seattle/
> >
> > Beware: It's only open on Sundays from 10 am to 3 pm, so if you want
> > to check it out, you'll have to come in early for it.
> >
> >
> > 2. The Space Needle is the iconic Seattle landmark. Buy tickets for
> > the time slot you want a couple days in advance. I personally like
> > watching the sunset from there.
> >
> > At the same complex as the space needle you can also catch the Museum
> > of Popular Culture and the 1962 World's Fair monorail. The monorail is
> > a 1962 vision of the future, with vintage German-built cars in good
> > working order.
> >
> > Short walk from the hotel to the Westlake monorail station, which will
> > take you over to the space needle.
> >
> >
> > 3. Pike Place Market is another Seattle icon. Moderate walk from the
> hotel.
> >
> >
> >
> > 4. Museum of Flight (this is Boeing's home town, so it's a high
> > quality aircraft museum)
> > https://www.museumofflight.org/
> >
> >
> > 5. Snoqualmie Falls Hydroelectric Museum and power plant
> > https://www.pse.com/en/pages/tours-and-recreation/snoqualmie-tours
> >
> >
> > 6. Northwest Railway Museum (also near Snoqualmie Falls)
> > https://www.trainmuseum.org/
> >
> > Beware that Snoqualmie Falls is a solid half hour outside of the city.
> >
> > Mt. Rainer, if you want to check it out, is a full-day trip: 2.5 hours
> > to get there, 2.5 hours to get back plus the time you spend in the
> > park. It's too far to catch it in an afternoon. Decent odds of getting
> > a shirtsleeves on the snow pack picture like this one:
> > https://bill.herrin.us/pictures/20210627-rainier/img-20210627-145745.jpg
> ,
> > which was also taken in June.
> >
> > Regards,
> > Bill Herrin
> >
> >
> >
> > On Tue, Mar 28, 2023 at 10:11 AM NANOG Support 
> wrote:
> > >
> > > Dear NANOG Community,
> > >
> > >
> > > NANOG 88 hybrid meeting, hosted by AWS will take place June 12-14,
> 2023 in Seattle, Washington.
> > >
> > >
> > > Registration Fees + Deadlines
> > >
> > > Hotel Guest Room Block
> > >
> > > VISA Requests
> > >
> > > Attendee List Poachers
> > >
> > >
> > > Registration Fees + Deadlines
> > >
> > > Meeting Registration:
> https://www.nanog.org/events/nanog-88/registration/
> > >
> > >
> > > In person Registration Rates
> > >
> > > Start Date
> > >
> > > End Date
> > >
> > > Member
> > >
> > > Non Member
> > >
> > > Student
> > >
> > > Early
> > >
> > > March 28, 2023
> > >
> > > April 9, 2023
> > >
> > > $675
> > >
> > > $700
> > >
> > > $100
> > >
> > > Standard
> > >
> > > April 10, 2023
> > >
> > > May 28, 2023
> > >
> > > $775
> > >
> > > $800
> > >
> > > $100
> > >
> > > Late
> > >
> > > May 29, 2023
> > >
> > > June 10, 2021
> > >
> > > $875
> > >
> > > $900
> > >
> > > $100
> > >
> > > Onsite
> > >
> > > June 11, 2023
> > >
> > > June 14, 2023
> > >
> > > $1,075
> > >
> > > $1,100
> > >
> > > $100
> > >
> > > If you are not able to join us in Seattle, Virtual
> Registration is available for $100.
> > >
> > >
> > > Registration Add Ons:
> > >
> > > Guest passes need to be purchased at the time you register. If you
> wish to add a guest pass after you register your guest pass will need to be
> purchased in person in Seattle.
> > >
> > > Monday Social Event Guest Pass: $50 per guest (purchase separately
> when you register, limit 2)
> > >
> > > Tuesday Night Beer N Gear Pass: $50 per guest (purchase separately
> when you reg

Re: Namecheap's outbound email flow compromised: valid rdns, spf, dkim and dmarc on phishes

[Eric Kuhnke]

Namecheap has updated their status page item to include

"We have stopped all the emails (that includes Auth codes delivery, Trusted
Devices’ verification, and Password Reset emails, etc.)"


Yikes.


On Sun, Feb 12, 2023, 3:54 PM Michael Thomas  wrote:

> I think that it might be appropriate to name and shame the third party,
> since they should know better too. It almost has the whiff of a scam.
>
> Mike
> On 2/12/23 3:49 PM, Eric Kuhnke wrote:
>
> One very possible theory is that whoever runs the outbound marketing
> communications and email newsletter demanded the keys and got them, with
> execs overriding security experts at Namecheap who know better.
>
> I would sincerely hope that the people whose job titles at Namecheap
> include anything related to network engineering, network security or
> cryptography at that company do know better. Large domain registrars are
> not supposed to make such a rookie mistake.
>
>
> On Sun, Feb 12, 2023, 3:46 PM Michael Thomas  wrote:
>
>>
>> On 2/12/23 3:40 PM, Eric Kuhnke wrote:
>> >
>> https://www.namepros.com/threads/concerning-e-mail-from-namecheap.1294946/page-2#post-8839257
>> >
>> >
>> > https://lowendtalk.com/discussion/184391/namecheap-hacked
>> >
>> > It looks like a third party service they gave their keys to has been
>> > compromised. I got several phishes that fully pass as legit Namecheap
>> > emails.
>> >
>> > https://www.namecheap.com/status-updates/archives/74848
>> >
>> >
>> If they actually gave them their own private keys, they clearly don't
>> get how that's supposed to work with DKIM. The right thing to do is
>> create a new selector with the third party's signing key. Private keys
>> should be kept... private.
>>
>> Mike
>>
>>

Re: Namecheap's outbound email flow compromised: valid rdns, spf, dkim and dmarc on phishes

[Eric Kuhnke]

One very possible theory is that whoever runs the outbound marketing
communications and email newsletter demanded the keys and got them, with
execs overriding security experts at Namecheap who know better.

I would sincerely hope that the people whose job titles at Namecheap
include anything related to network engineering, network security or
cryptography at that company do know better. Large domain registrars are
not supposed to make such a rookie mistake.


On Sun, Feb 12, 2023, 3:46 PM Michael Thomas  wrote:

>
> On 2/12/23 3:40 PM, Eric Kuhnke wrote:
> >
> https://www.namepros.com/threads/concerning-e-mail-from-namecheap.1294946/page-2#post-8839257
> >
> >
> > https://lowendtalk.com/discussion/184391/namecheap-hacked
> >
> > It looks like a third party service they gave their keys to has been
> > compromised. I got several phishes that fully pass as legit Namecheap
> > emails.
> >
> > https://www.namecheap.com/status-updates/archives/74848
> >
> >
> If they actually gave them their own private keys, they clearly don't
> get how that's supposed to work with DKIM. The right thing to do is
> create a new selector with the third party's signing key. Private keys
> should be kept... private.
>
> Mike
>
>

Namecheap's outbound email flow compromised: valid rdns, spf, dkim and dmarc on phishes

[Eric Kuhnke]

https://www.namepros.com/threads/concerning-e-mail-from-namecheap.1294946/page-2#post-8839257

https://lowendtalk.com/discussion/184391/namecheap-hacked

It looks like a third party service they gave their keys to has been
compromised. I got several phishes that fully pass as legit Namecheap
emails.

https://www.namecheap.com/status-updates/archives/74848

Re: Yondoo provided router, has "password" as admin pw, won't let us change it

[Eric Kuhnke]

I agree, but if we start listing every massive security vulnerability that
can be found on the intra-home LAN in consumer-grade routers and home
electronics equipment, or things that people operate in their homes with
the factory-default passwords, we'd be here all month in a thread with 300
emails.

I'm sure this ISP will realize what a silly thing they did if and when some
sort of worm or trojan tries a set of default logins/passwords on whatever
is the default gateway of the infected PC, and does something like rewrite
the IPs entered for DNS servers to send peoples' web browsing to
advertising for porn/casinos/scams, male anatomy enlargement services or
something.



On Wed, Feb 8, 2023 at 3:28 PM William Herrin  wrote:

> On Wed, Feb 8, 2023 at 2:36 PM Eric Kuhnke  wrote:
> > I would hope that this router's admin "password" interface is only
> accessible from the LAN side.
> > This is bad, yes, but not utterly catastrophic.
>
> It means that any compromised device on the LAN can access the router
> with whatever permissions the password grants. While there are
> certainly worse security vulnerabilities, I'm reluctant to describe
> this one as less than catastrophic. Where there's one grossly ignorant
> security vulnerability there are usually hundreds.
>
> Regards,
> Bill Herrin
>
>
> --
> For hire. https://bill.herrin.us/resume/
>

Re: Yondoo provided router, has "password" as admin pw, won't let us change it

[Eric Kuhnke]

I would hope that this router's admin "password" interface is only
accessible from the LAN side. It's not listening to the world for a login
with "password", right?  Have you port scanned its WAN interface and tried
connecting to it to see what's listening?

This is bad, yes, but not utterly catastrophic. Generally in a situation
where somebody has physical access to a home
Netgear/Linksys/TP-Link/whatever type router, they could physically push
the factory reset button and gain access to its admin interface to
reconfigure it however they wanted anyways.

I think there's a value for discussion in nanog about how to provision and
set up residential last mile services that work right, but this isn't
exactly a wider spread network operational issue unless you've discovered
thousands of CPEs that can be accessed by "password" from the outside
Internet.





On Tue, Feb 7, 2023 at 6:18 AM TACACS Macaque via NANOG 
wrote:

> Hi,
>
> Long time lurker, first time poster. Sorry in advance if this is the wrong
> forum for something like this.
>
> My mom's ISP (Yondoo) seems to be providing DOCSIS 3.1 CPE (Customer
> Premises Equipment) with a built-in router, without providing the ability
> to change the admin password from "password" on it.
>
> [image: Screenshot 2023-02-03 at 9.49.15 PM.png]
>
> ​[image: Screenshot 2023-02-03 at 9.51.51 PM.png]
>
> Their customer service rep said that this is not only WAI, but also wanted
> to charge her $50 to have a tech come out and change it. Which is obviously
> less than ideal.
>
> That aside, this seems like a pretty egregious security standard which,
> from my understanding, can have fairly dire security implications... e.g.,
> DNS server settings can be pointed at whatever someone wants here.
>
> My mom is elderly and had already fallen victim to a call center scammer a
> couple years ago. They briefly took control over her laptop before she
> called for backup. So I'm just a little concerned that we have no control
> over changing this router's admin password — from “password” — in a pinch,
> without waiting for a truck roll && shelling out $50.
>
> I've sent her a DOCSIS 3.1 modem that doesn't have a router built-in, in
> hopes that they'll let us bring our own. She does have Google Wifi, but we
> can't even put their router into bridge mode. So she would be double NATed
> *and* have no control over changing the admin password on the first
> router.
>
> Anyone have any experience with Yondoo? I've tried reaching out to them on
> multiple fronts, but have yet to hear back from them on this. A tech is
> scheduled to come out tomorrow, so the plan is to beg (bribe?) them to let
> us use our own modem and then take it from there.
>
> Thanks,
> Todd
>

Re: Increasing problems with geolocation/IPv4 access

[Eric Kuhnke]

One would also think that large OTT content providers which publish Android
and IOS apps could use the geolocation-permission data gathered from the
device, telemetry reported to their own internal systems to gather their
own independent data sets on where customers are geographically located, at
least as coarse to a specific metro area.. And use that to clean up
geolocation features where 3rd party IP geolocation datasets don't match
reality.

At the smallest scale of customer count: For instance if they have many
dozens or hundreds of subscribers whose devices often sign in from the same
/24 block, *and* in which that block is not known to be cellular
carrier/MNO/MVNO IP space, *and* the devices' geolocation API data reports
they're in a certain suburb of Portland. Or even if you have something like
a smart TV in a house which has no geolocation ability/API exposed but many
of the customers' *other* devices which *do* report geolocation API often
sign in to the same account from the same residential-last-mile-provider
dhcp pool /32 address.

The amount of telemetry data collected off an android or ios devices these
days by most consumer apps is quite comprehensive, and as we all known the
average person is extremely likely to click "Yes/accept" on any
software/interface modal popups, so the majority of the devices will not
have geolocation blocked.  They already have whole teams of highly paid
software developers working on the DRM-specific code in their video
streaming apps, so clearly some use of that data is made already.





On Sat, Feb 4, 2023 at 11:41 PM John van Oppen  wrote:

> Honestly, the only way I’ve found to fix this is completely fill it with
> subscribers off a BNG and give support a script about what to tell
> customers.
>
>
>
> I’ve had folks literally get the wrong TV channels because we assign
> unused blocks in Portland Oregon out of our parent large aggrigates and the
> geo folks have our whois address in the seattle area so give them seattle
> channels.God forbid these OTT folks just design the product right and
> use the verified billing zip code on the account or something else that
> actually is authoritative.
>
>
>
> *From:* NANOG  *On Behalf Of *Josh
> Luthman
> *Sent:* Monday, January 23, 2023 1:09 PM
> *To:* Jared Mauch 
> *Cc:* nanog 
> *Subject:* Re: Increasing problems with geolocation/IPv4 access
>
>
>
> Every block I've gotten I just went through TheBrothersWisp geo location
> page and just had them fix their information.  This includes virgin and
> re-issued blocks from ARIN.
>
>
>
> I've had a couple of random issues like Hulu thinking I'm a VPN, PSN
> blocking a /24 because a /32 failed his password too many times, and
> various streaming issues of which I tell customers to complain to the
> streaming provider because all of the other ones work.
>
>
>
> On Fri, Jan 20, 2023 at 7:32 PM Jared Mauch  wrote:
>
> I’ve been seeing an increasing problem with IP space not having the
> ability to be used due to the behaviors of either geolocation or worse,
> people blocking IP space after it’s been in-use for a period of time.
>
> Before I go back to someone at ARIN and say “your shiny unused 4.10 IP
> space” is non-functional and am at a place where I need to
> start/restart/respawn the timer, I have a few questions for people:
>
> 1) Do you see 23.138.114.0/24 in any feeds from a security provider that
> say it can/should be blocked?  If so, I’d love to hear from you to track
> this down.  Over the new year we had some local schools start to block this
> IP space.
>
> 2) many companies have geolocation feeds and services that exist and pull
> in data.  The reputable people are easy to find, there are those that are
> problematic from time-to-time (I had a few customers leave Sling due to the
> issues with that service).
>
> 3) Have you had similar issues?  How are you chasing all the issues?
> We’ve seen things from everything works except uploading check images to
> banks, to other financial service companies block the space our customers
> are in.  If we move them to another range this solves the problem.
>
> 4) We do IPv6, these places aren’t IPv6 modern at all, so that’s no help.
>
> 5) IRR+geofeed are published of course.  I’m thinking that it might be
> worthwhile that IP space have published placeholders when it’s well
> understood, eg: ARIN 4.9 space, I can predict what our next allocation
> would be, it would be great to have it be pre-warmed.
>
> I’ve only seen a few complaints against all our IP space over time, so I
> don’t think there’s anything malicious coming from the IP space to justify
> it, but it’s also possible they didn’t make it through.
>
> If you’re with the FKA Savvis side, can you also ping me, I’d like to see
> if you can reach out to our most recent complaint source to see if we can
> find who is publishing this.  Same if you’re with Merit or the Michigan
> Statewide Educational Network - your teachers stopped being able to post to
> powers

Re: Spectrum (legacy TWC) Infrastructure - Contact Off List

[Eric Kuhnke]

There is "microtrenching" and then there is microtrenching. Very different
things are sometimes described by the same name. Some of what Google tried
to go was exceedingly shallow, like 4 inches down. Cheap microtrenching
done too quick and too shallow has given the concept a bad name.

There is microtrenched fiber in Vancouver BC that is close to 20 years old
now throughout the downtown core that is nearly problem-free. The
difference is that it is 12+ inches down and was installed using large,
noisy, water cooled diamond-grit concrete saws cutting deep slits into the
joints between streets and curbs, or concrete curbs and sidewalks,  duct
inserted, then backfilled with grouting. It's deep enough where it crosses
roads that re-paving the road by first grinding off the top several inches
of surface is extremely unlikely to disturb the duct.

On Thu, Feb 2, 2023 at 5:17 PM Clayton Zekelman  wrote:

>
> It may.  We don't use it.  Too many freeze/thaw cycles each winter around
> here.  It would get destroyed in a few years.
>
> Google tried to cheap out in Louisville... didn't quite work out
> https://www.theverge.com/2019/2/7/18215743/google-fiber-leaving-louisville-service-ending
> - although that was even more sketchy than traditional microtrenching.
>
> As for rural, the business case becomes even more difficult when you're
> measuring kilometers per home passed instead of homes passed per
> kilometer...
>
> At 07:58 PM 02/02/2023, Kevin Shymkiw wrote:
>
> Clayton,
>
> Did you leverage things like micro trenching for this project?  I may be
> mislead, but I thought micro trenching these days has helped drive the cost
> of doing this down fairly significantly.
>
> Kevin
>
> On Thu, Feb 2, 2023 at 17:56 Clayton Zekelman  wrote:
>
> The cost is not low.  Trust me on that.  I've been involved in a pretty
> massive suburban fibre deployment for the past decade... I expect we'll
> make money sometime in the 2030's... in time for me to retire.
>
> At 12:13 PM 02/02/2023, Forrest Christian (List Account) wrote:
>
> The cost to build physical layer in much of the suburban and somewhat
> rural US is low enough anymore that lots of smaller, independent, ISPs are
> overbuilding the incumbent with fiber and taking a big chunk of their
> customer base because they are local and care.  And making money while
> doing it.Â
>
>
> --
>
> Clayton Zekelman
> Managed Network Systems Inc. (MNSi)
> 3363 Tecumseh Rd. E
> Windsor, Ontario
> N8W 1H4
>
> tel. 519-985-8410
> fax. 519-985-8409
>

Re: Spectrum (legacy TWC) Infrastructure - Contact Off List

[Eric Kuhnke]

It might look low cost until you look at a post-1980s suburb in the USA or
Canada where 100% of the utilities are underground. There may be no fiber
or duct routes. Just old coax used for DOCSIS3 owned/run by the local cable
incumbent and copper POTS wiring belonging to the ILEC. The cost to
retrofit such a neighborhood and reach every house with a fiber
architecture can be quite high in construction and labor.



On Thu, Feb 2, 2023 at 9:14 AM Forrest Christian (List Account) <
li...@packetflux.com> wrote:

> The cost to build physical layer in much of the suburban and somewhat
> rural US is low enough anymore that lots of smaller, independent, ISPs are
> overbuilding the incumbent with fiber and taking a big chunk of their
> customer base because they are local and care.  And making money while
> doing it.
>
>
> On Thu, Feb 2, 2023, 8:22 AM Masataka Ohta <
> mo...@necom830.hpcl.titech.ac.jp> wrote:
>
>> Mike Hammett wrote:
>>
>> > I selfishly hope they don't because that's where independent
>> > operators will succeed. ;-)
>>
>> Because of natural regional monopoly at physical layer (cabling
>> cost for a certain region is same between competitors but their
>> revenues are proportional to their regional market shares), they
>> can't succeed unless the physical layer is regulated to be
>> unbundled, which is hard with PON.
>>
>> But, in US where regional telephone network has been operated
>> by, unlike Europe/Japan, a private company enjoying natural
>> regional monopoly, economic situation today should be no worse
>> than that at that time.
>>
>> Masataka Ohta
>>
>

Re: Spectrum (legacy TWC) Infrastructure - Contact Off List

[Eric Kuhnke]

I think that this really says more about the race to the bottom in last
mile residential operations.

It seems inevitable that once a last mile residential broadband operator
grows to a certain gargantuan size, the quality of the network suffers and
nobody really cares to take ownership of specific local problems.

I've seen it many times looking at infrastructure of probably a dozen
different last mile operators in many different states and provinces.

And do you know what's commonly found in the same places as stuff like
garbage bag wrapped pedestals and coax temp-run between cans for months or
years at a time?  Employees who feel pressured to do cheap/shoddy/fast work
and move on to the next ticket. Or workers doing these tasks who aren't
employees at all but piece work 1099 workers under a subcontract or a
subcontractor-of-a-contractor.  It's not a good situation for the rank and
file workers either. Go find the worker who eventually fixes that temp-run
coax job and see if he's really happy with his job.

I wish that the people running the networks at residential last mile
operators with many hundreds of thousands up to dozens of millions of CPEs
would push back against efforts from executives/management to participate
in this race to the bottom of cost and network quality. It's too easy to
hand wave away the problem and be like "oh, but the middle mile fiber
aggregation router and core links in and out of this market look fine,
that's somebody else's problem to deal with the field work...".





On Tue, Jan 31, 2023 at 1:36 PM Gabriel Kuri via NANOG 
wrote:

> Could someone from Spectrum who deals with the HFC infrastructure in
> Southern California, specifically the legacy Time Warner Cable area,
> contact me off list ?
>
> Apparently the local infrastructure crew thinks it's OK to leave cable
> running between two cans in a residential neighborhood since at least July
> 2022. But it's OK, because they've cautioned them off with orange cones,
> right ?
>
> Multiple calls to regular customer service fall on deaf ears about a coax
> trunk cable run above ground on a street and sidewalk in the middle of a
> residential neighborhood.
>
> Customer service says, "We don't know what you're talking about, we don't
> have cables running on the street". Can't seem to get a hold of the right
> people to come out and get it buried and get rid of the eyesore and safety
> hazard ...
>
> [image: image1.jpg]
>
> [image: image2.jpg]
>
> Thanks,
> Gabe
>

Re: Smaller than a /24 for BGP?

[Eric Kuhnke]

> 1) It's amazing how many threads end up ending in the (correct) summary
that making an even minor global change to the way the internet works
and/or is configured to enable some potentially useful feature isn't likely
to happen.

My biggest take-away from this is that software and network engineering
design decisions should be more thoughtful and methodical when setting
address space, number space, name space and size/expandability of whatever
is being configured when designing new things. Even if you think whatever
you've created is inexhaustible for your own purposes. Once something has
been put into widespread use it's extremely difficult to come back and fix
it later.

Such as for ISP internal purposes, like thinking about "okay what if we
take this DNS zone delegation for our internal management network and set
it aside for a vast number of CPEs in the future, hierarchically organized
by where they're going to be installed geographically, for our internal
hostnames and reverse DNS".

I'm sure that the vast global address space of ipv4 looked incredibly large
when put into use as a standard...

Or if you've ever seen an organization that internally set up its
accounting/billing/customer circuit ID system with a namespace/number-space
that didn't scale to meet future needs, or categorization of customers, or
integration of circuit IDs into automation systems.



On Tue, Jan 24, 2023 at 8:13 PM Forrest Christian (List Account) <
li...@packetflux.com> wrote:

> I have two thoughts in relation to this:
>
> 1) It's amazing how many threads end up ending in the (correct) summary
> that making an even minor global change to the way the internet works
> and/or is configured to enable some potentially useful feature isn't likely
> to happen.
>
> 2) I'd really like to be able to tag a BGP announcement with "only use
> this announcement as an absolute last resort" so I don't have to break my
> prefixes in half in those cases where I have a backup path that needs to
> only be used as a last resort.  (Today each prefix I have to do this with
> results in 3 prefixes in the table where one would do).
>
> And yes. I know #2 is precluded from actually ever happening because of
> #1.   The irony is not lost on me.
>
>
> On Tue, Jan 24, 2023, 7:54 PM John Levine  wrote:
>
>> It appears that Chris J. Ruschmann  said:
>> >-=-=-=-=-=-
>> >How do you plan on getting rid of all the filters that don’t accept
>> anything less than a /24?
>> >
>> >In all seriousness If I have these, I’d imagine everyone else does too.
>>
>> Right. Since the Internet has no settlements, there is no way to
>> persuade a network of whom you are not a customer to accept your
>> announcements if they don't want to, and even for the largest
>> networks, that is 99% of the other networks in the world. So no,
>> they're not going to accept your /25 no matter how deeply you believe
>> that they should.
>>
>> I'm kind of surprised that we haven't seen pushback against sloppily
>> disaggregated announcements.  It is my impression that the route table
>> would be appreciably smaller if a few networks combined adjacent a
>> bunch of /24's into larger blocks.
>>
>> R's,
>> John
>>
>

Re: Starlink routing

[Eric Kuhnke]

I think it's useful to clarify terminology - the starlink antenna unit
itself is the CPE.  With my v1 starlink terminal you can plug literally
anything into the PoE injector that is a 1500 MTU 1000BaseT DHCP client and
it'll get an address and a default route out to the internet. All of the
smarts happen in the antenna unit/phased array unit which also has its own
fairly capable embedded CPU/RAM and routing capability.

The starlink *indoor* CPE, the home wifi router itself ,is a very basic
thing that looks like something derived from a Taiwan ODM 802.11ac home
router OpenWRT reference design with a custom firmware load.Or similar. If
you've seen a teardown of one they're very simple.

With the v2 rectangular terminals it's similar but you need a cable adapter
to go from the proprietary starlink cable to indoor unit, and additionally
the indoor CPE unit also serves as the PoE injector.

In some other ISP type environments you might be expecting the indoor unit
to be the CPE, such as what you'd get with a Comcast DOCSIS3.0 all-in-one
modem+coax interface+router+wifi device attached to some coax coming in
through a wall.



On Mon, Jan 23, 2023 at 3:36 PM Michael Thomas  wrote:

>
> On 1/23/23 3:14 PM, Eric Kuhnke wrote:
> > The original and traditional high-cost way of how this is done for
> > MEO/LEO is exemplified by an o3b terminal, which has two active
> > motorized tracking antennas. The antenna presently in use for the
> > satellite that is overhead follows it until it's descending towards
> > the horizon, while at the same time the second antenna aims itself at
> > where the next 'rising' satellite is predicted to appear at the
> > opposite horizon, and forms a link to it. Make-before-break. If anyone
> > has seen photographs in their marketing material/videos of the Oneweb
> > beta test earth stations in Alaska they are operating using the same
> > general concept.
> >
> > Oneweb has clearly positioned their market focus for telecoms and ISPs
> > and large enterprise end users, because their CPE equipment is
> > considerably larger, expensive and more power hungry. The beta test
> > sites I've seen installed on top of a telecom equipment shelter occupy
> > an area approximately 8 feet long x 4 feet wide including radomes and
> > mounting.
> >
> I'm trying to understand this so sorry if this comes off dumb. So does
> the base station mediate all handoffs where the CPE is told when/what to
> handoff? Or does the CPE have some part in it (other than receiving the
> handoff)? Does the CPE accept control traffic (L2?) from any bird? Are
> there cases where the CPE needs to de-dup packets due to handoffs?
>
> This is pretty fascinating stuff.
>
> Mike
>
>

Re: Starlink routing

[Eric Kuhnke]

The original and traditional high-cost way of how this is done for MEO/LEO
is exemplified by an o3b terminal, which has two active motorized tracking
antennas. The antenna presently in use for the satellite that is overhead
follows it until it's descending towards the horizon, while at the same
time the second antenna aims itself at where the next 'rising' satellite is
predicted to appear at the opposite horizon, and forms a link to it.
Make-before-break. If anyone has seen photographs in their marketing
material/videos of the Oneweb beta test earth stations in Alaska they are
operating using the same general concept.

Oneweb has clearly positioned their market focus for telecoms and ISPs and
large enterprise end users, because their CPE equipment is considerably
larger, expensive and more power hungry. The beta test sites I've seen
installed on top of a telecom equipment shelter occupy an area
approximately 8 feet long x 4 feet wide including radomes and mounting.

On Mon, Jan 23, 2023 at 2:49 PM Kevin McCormick  wrote:

> My original thought was this would be more like Client Optimized Roaming
> with WiFi access points.
>
> Communication between the client dish or base station and satellites to
> transparently move client dish and base station from satellites moving out
> of view to a satellite in view.
>
> Kevin McCormick
>
>
> -Original Message-
> From: NANOG  On Behalf Of
> Michael Thomas
> Sent: Sunday, January 22, 2023 4:43 PM
> To: nanog@nanog.org
> Subject: Starlink routing
>
> CAUTION: This email originated from outside your organization. Exercise
> caution when opening attachments or clicking links, especially from unknown
> senders.
>
> I read in the Economist that the gen of starlink satellites will have the
> ability to route messages between each satellite. Would conventional
> routing protocols be up to such a challenge? Or would it have to be custom
> made for that problem? And since a lot of companies and countries are
> getting on that action, it seems like fertile ground for (bad) wheel
> reinvention?
>
> Mike
>
>

Re: Starlink routing

[Eric Kuhnke]

For the people who have seen their US48 state earth station setups in
person it is pretty normal on the network level. Being colocated with major
inter-city long haul dark fiber DWDM regen sites (Level3 dark fiber path
Seattle to Boise, ID which has a regen hut site in Prosser, WA is a perfect
example) gives them the ability to buy a transport circuit to the nearest
major city/IX point and haul traffic there. I believe they're buying single
100 Gbps waves.


On Mon, Jan 23, 2023 at 2:18 PM Chris J. Ruschmann 
wrote:

> Don’t quote me on this, but I wouldn’t say they are doing anything
> different than you or I can do and have access to on the routing layer.
> It's probably just Nokia and Arista and whatever those systems provide.
> Stuff like Tunneling, ECMP, BFD and VxLan... Think spatially coordinated
> Zerotier and not based on latency. They also have a pretty good team of
> experts that have experience with large scale networking and automation
> they've plucked from various places.
>
> How the Satellites talk to the end users is where all the magic is. But my
> understanding is that it's all custom developed networking as code that
> handles all the frequency coordination and hand offs with the ground.
>
> -Original Message-
> From: NANOG  On Behalf Of
> Michael Thomas
> Sent: Sunday, January 22, 2023 1:43 PM
> To: nanog@nanog.org
> Subject: Starlink routing
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
>
> I read in the Economist that the gen of starlink satellites will have the
> ability to route messages between each satellite. Would conventional
> routing protocols be up to such a challenge? Or would it have to be custom
> made for that problem? And since a lot of companies and countries are
> getting on that action, it seems like fertile ground for (bad) wheel
> reinvention?
>
> Mike
>
>

Re: Starlink routing

[Eric Kuhnke]

My present understanding is that starlink satellites with lasers are not
designed to communicate inter-plane. Each launch of starlink satellites is
put into exactly the same orbital inclination (53.2 degrees or the more
rare near polar orbits now launched from Vandenberg).

In the weeks and months following their launch they spread out into an
extended line all following each other in the same plane. Plane change
maneuvers are extremely expensive in delta-v for any satellite and are
generally avoided unless absolutely necessary. Best conjecture is that
starlink satellites' on board propellant for hall effect or ion thrusters
(or whatever they're using that has an ISP above 3000) is used almost
exclusively for thrusting prograde to maintain altitude.

If you view a launch of 45 or 50 starlink satellites in a live animated
satellite tracking application, based on their TLE orbital data, they all
follow each other in a line. Satellites in the same line may be using
inter-satellite lasers to speak to the unit immediately in front of it, and
immediately behind it, forming a conga-line like network of linked
satellites until they get to one that is generally above a starlink earth
station/terrestrial network facility. At which point the traffic is
transferred.

Starlink has recently made service available for purchase in Nunavut and
all of the other high-latitude areas of northern Canada, which means that
they clearly think they have sufficient (82 degree plus) inclination sets
of satellites *and* inter-satellite links working to provide service in an
area that definitely has no terrestrial fiber or starlink earth stations.



On Mon, Jan 23, 2023 at 11:29 AM Thomas Bellman  wrote:

> On 2023-01-23 19:08, I wrote:
>
> > I get that for 1310 nm light, the doppler shift would be just under
> > 0.07 nm, or 12.2 GHz:
> > [...]
> > In the ITU C band, I get the doppler shift to be about 10.5 GHz (at
> > channel 72, 197200 GHz or 1520.25 nm).
> > [...]
> > These shifts are noticably less than typical grid widths used for
> > DWDM (±50 GHz for the standard spacing), so it seems unlikely to me
> > that the doppler shift would be a problem.
>
> And as I was bicycling home, I of course thought of another aspect
> of the doppler shift: the timing between the symbols in the signal,
> or in other words the baud rate.  There will be something like a
> phase-locked loop (PLL) in the receiver in order to know when one
> symbol ends and the next one starts, and that PLL can only deal
> with a certain amount of baud rate shift.
>
> But we can use the same formula.  And in general, the doppler shift
> for 16 km/s is about 53 parts per million.  So e.g. a 112 Gbaud signal
> would be received as 6 Mbaud faster or slower than it was sent at.
> And here I have to confess that I don't know how generous typical
> receiver PLL:s in network equipment are.
>
>
> Another potential aspect might be the decoding of phase-shift keying,
> i.e. when phase modulation is used for the signal.  My *very*vague*
> understanding is that the typical way to decode a phase-modulated
> signal, is to mix the incoming signal with a reference carrier wave,
> generated locally by the receiver, and the interference between the
> two gives you the actual signal.  But to do that, the reference must
> have the same frequency as the received wave, and, I guess, must
> match very closely.  Can they adapt to an incoming wave that is 53 ppm
> offset from what it should be?
>
> Or have I misunderstood this?  Analogue signals is very much *NOT*
> my forte...
>
>
> /Bellman
>
>

Re: starlink downlink/internet access

[Eric Kuhnke]

AS14593 is not new, they joined the SIX 3+ years ago, from an
outside-of-spacex view they have just recently within the past 12 months
started putting it into more widespread use.



On Wed, Jan 11, 2023 at 11:10 AM Mike Hammett  wrote:

> Here's their new stuff:
>
> https://bgp.he.net/AS14593
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions 
> 
> 
> 
> 
> Midwest Internet Exchange 
> 
> 
> 
> The Brothers WISP 
> 
> 
> --
> *From: *"Eric Dugas via NANOG" 
> *To: *"Tom Beecher" 
> *Cc: *nanog@nanog.org
> *Sent: *Wednesday, January 11, 2023 10:23:15 AM
> *Subject: *Re: starlink downlink/internet access
>
> Starlink has nothing to do with Google Fiber. It used to use Google Cloud
> for routing (BYOIP) in the early days but I am sure this has changed.
>
> Eric
>
> On Wed, Jan 11, 2023 at 9:51 AM Tom Beecher  wrote:
>
>> I can say with certainty at least one downlink location is not using
>> Google Fiber, as I am sitting about 1/2 mile from it , and have firsthand
>> knowledge of all glass in the ground around here.
>>
>> On Wed, Jan 11, 2023 at 12:14 AM Dave Taht  wrote:
>>
>>> I maintain an email list for issues specific to starlink here:
>>> https://lists.bufferbloat.net which has multiple experts on it. There
>>> are also quite a few folk on twitter covering what's going on there.
>>>
>>> The latest information I had was that they'd started off hooked up to
>>> google's stuff but have been building out their own network wherever
>>> they can.
>>>
>>>
>>> On Tue, Jan 10, 2023 at 8:50 PM Ong Beng Hui 
>>> wrote:
>>> >
>>> > Hi folks,
>>> >
>>> > Anyone know/advise if Starlink internet downlink is in US Google fiber
>>> ?
>>> > I thought I saw a message before that Starlink was using Google fiber.
>>> >
>>> > I was referring to the actual internet transit, not the Satellite
>>> > downlink station.
>>> >
>>> > Please advise.
>>> >
>>>
>>>
>>> --
>>> This song goes out to all the folk that thought Stadia would work:
>>>
>>> https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
>>> Dave Täht CEO, TekLibre, LLC
>>>
>>
>

Mozilla and others move to distrust the "Trustcor" CA

[Eric Kuhnke]

https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/oxX69KFvsm4/m/yLohoVqtCgAJ

Start from the top post for a full history.

Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC

[Eric Kuhnke]

Assume the following theoretical scenario:

You have a large number of existing RIPE, ARIN, APNIC ASes which will take
any ipv4 resources they can get. They're all on waiting lists or have been
informed no new blocks will be forthcoming.

240/4 is something like 256 million IPs.

Let's say that the global benevolent ipv4 dictator decides that each ISP,
MNO or other waiting list entity gets a single /16, one time only.

That's 64,000 IPs per corporate entity. Not actually very large at all on
the scale of regional mid sized operators with 300,000 last mile broadband
subscribers, or mobile network operators, nevermind top-10-size
DOCSIS3/GPON/DSL last mile operators that have many dozens of millions of
customers. One /16 is a tiny drop in the bucket compared to the demand for
IP space for indivudual-customer DHCP pool usage by an ISP the size of
Astound or a South Korean GPON operator or similar.

That's 4000 entities which each get their one time /16 and then 240/4 is
entirely exhausted.

Unrealistic?  Halve it so that each network operator waiting for IP space
reources gets one/ 17, one time only, I would still bet good money that
there's 8000 ASes out there that right now would happily take their "free
"single /17 , and you'd still have immediate complete exhaustion of 240/8.







On Mon, 21 Nov 2022 at 16:33, Joe Maimon  wrote:

>
>
> Eric Kuhnke wrote:
> > In a theoretical scenario where somebody was global benevolent
> > dictator of ipv4 space, even applying a policy which limited block
> > size to a few /14 per ISP, it would be possible to exhaust 240/4/in
> > one week/ if they handed out /14 sized pieces to every existing last
> > mile LTE network operator with 5+ million customers globally. It is
> > not a long term solution or even a good medium term solution.
> >
> To to the LM LTE Operator with 5+ mill. customer globally, it is not.
> Agreed. Also, I think they have already sorted themselves out
> sufficiently in a variety of ways. I am not concerned with them, at all.
>
> Which is why I did not offer that as an example of useful constraint.
> Re-run your projections with what I actually discussed, I think you will
> have a different conclusion.
>
> Joe
>

Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC

[Eric Kuhnke]

In a theoretical scenario where somebody was global benevolent dictator of
ipv4 space, even applying a policy which limited block size to a few /14
per ISP, it would be possible to exhaust 240/4* in one week* if they handed
out /14 sized pieces to every existing last mile LTE network operator with
5+ million customers globally. It is not a long term solution or even a
good medium term solution.

On Mon, 21 Nov 2022 at 16:19, Joe Maimon  wrote:

> Eric,
>
> I appreciate your willingness to actual consider this rationally.
>
> Every facet of this debate has been fully aired on this forum (and
> others), numerous times.
>
> Allow me to pick it apart again. Apologies to those who are ad nausem.
>
> Eric Kuhnke wrote:
> > Option A) Spend engineering time and equipment purchases to implement
> > 240/4 as unicast globally. At present consumption rates and based on
> > the number of entities in ARIN, RIPE, APNIC regions that could
> > *immediately* take /18 to /16 sized blocks of it, please quantify
> > exactly how many years this amount of "new" IP space you predict to be
> > useful before once again reaching ipv4 exhaustion. End result: Problem
> > not solved. Thus my analogy of building a sand castle while the tide
> > is coming in.
> >
> > Option B) Spend engineering time and equipment purchases (yes, very
> > possibly much more time and more costly) to implement ipv6.
>
> This is know a false dichotomy. There is no actual reason to believe
> that any effort on option A detracts from available effort of option B.
> And when you purchase your new gear, or update the software, with its
> many many lines of code changes, it is not unreasonable to expect that
> at least some might be IPv4 related and that the removal of restriction
> on 240/4 would be the more trivial of those.
>
> Indeed that is exactly what has been happening since the initial
> proposals regarding 240/4. To the extent that it is now largely
> supported or available across a wide variety of gear, much of it not
> even modern in any way.
>
> Further, presentment of options in this fashion presumes that we have
> some ability to control or decide how engineering efforts across the
> entirety of the internet should be spent.
>
> Respectively, amusing and alarming.
>
> To be clear, the only thing preventing the Internet in freely organizing
> its own efforts is the unwillingness of curmudgeons to remove the
> reserved status in this particular instance.
>
> As no-one is requesting that you (or others of this persuasion) lend
> their personal efforts, your concern on the budgeting of efforts is out
> of place and worse, of dictatorial bend.
>
> For the sake of argument, ignoring above, presuming our control over the
> internet engineering efforts et al.
>
> Were I to propose to you that 240/4 be utilized only for new or existing
> organizations with less than /20 total resources or some other useful
> constraint, it would be easy to see that 240/4 would last a very long
> time and potentially have quite a significant impact.
>
> Earlier in this thread I contrasted a reduction from 12 to 1 of ip
> address consumption per new customer, depending on the practices
> employed by the service provider. As you can see, consumption rate is
> actually quite flexible, even now, today.
>
> So the answer to your question is it depends how freely it is handed
> out. Certainly not very long if it is business as usual prior to runout.
> Potentially much longer if not.
>
> And in a nod to your concern over effort expenditure, but even more so,
> conscious of 240/4 being the 32bit space last big easy gasp, I would be
> a strong proponent that it NOT be.
>
> However, even if it were, what exactly are we saving it for, if not for
> use by those who need it?
>
> Or is it to be a hedge over some eventuality where IPv6 has failed to
> the point of abandonment? I might actually respect that position, even
> as I doubt (and fear and hope against) such an eventualities actual
> occurrence.
>
> The more galling aspect of the 240/4 wars is that "it will take too long
> and then Ipv6 will be deployed" crowd that managed to stifle it
> initially continue to reuse that line again, in essence blase self
> perpetuation.
>
> Its only taking that long because of this attitude.
>
> Joe
>
>
>

Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC

[Eric Kuhnke]

Option A) Spend engineering time and equipment purchases to implement 240/4
as unicast globally. At present consumption rates and based on the number
of entities in ARIN, RIPE, APNIC regions that could *immediately* take /18
to /16 sized blocks of it, please quantify exactly how many years this
amount of "new" IP space you predict to be useful before once again
reaching ipv4 exhaustion. End result: Problem not solved. Thus my analogy
of building a sand castle while the tide is coming in.

Option B) Spend engineering time and equipment purchases (yes, very
possibly much more time and more costly) to implement ipv6.


Even if option B is much more costly and time consuming, the end result
will be much better.



On Mon, 21 Nov 2022 at 14:48, Joe Maimon  wrote:

>
>
> Eric Kuhnke wrote:
> > Quite simply, expecting the vast amount of legacy ipv4-only equipment
> > out there in the world that is 10, 15, 20 years old to magically
> > become compatible with the use of 240/4 in the global routing table is
> > a non viable solution. It is not a financial reality for many small to
> > medium sized ISPs in lower income countries.
> >
> > The amount of time and effort that would be required to implement your
> > proposal is much better spent on ipv6 implementation and various forms
> > of improved cgnat.
>
> In specific focus on 240/4
>
> Simultaneously claiming that enabling 240/4 as unicast involves
> difficulty that in comparison makes IPv6 (and then you add in CGNAT!)
> somehow more achievable is ridiculous.
>
> Regardless of the exact scenario.
>
> Joe
>
>
>

Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC

[Eric Kuhnke]

Quite simply, expecting the vast amount of legacy ipv4-only equipment out
there in the world that is 10, 15, 20 years old to magically become
compatible with the use of 240/4 in the global routing table is a non
viable solution. It is not a financial reality for many small to medium
sized ISPs in lower income countries.

The amount of time and effort that would be required to implement your
proposal is much better spent on ipv6 implementation and various forms of
improved cgnat.

Trying to extend the use of ipv4 space resources for a few more years is
directly analogous to building sand castles on the beach when the tide is
obviously coming in.




On Mon, 21 Nov 2022 at 07:29, Abraham Y. Chen  wrote:

> Dear Eric:
>
> 0) Your opinion by itself is very valid and much appreciate. However, it
> is from a very remotely related perspective. That is, you are looking at
> the financial disadvantage of the less developed regions. What I am
> talking about is the generic issue of communication system address
> management that applies across the board. This subject is normally
> designed by system planners. The result is given to the product
> development engineers who usually do not have enough knowledge to
> question it.
>
> 1)  The IPv4 address pool depletion issue was caused by the poor
> "resources management" concepts. In this case, the insistence on the
> Internet addressing should be flat (instead of hierarchical) led to the
> quick depletion of the finite sized 32-bit pool. The fact is that the
> current prevalent CDN (Content Delivery Network) business model based on
> CG-NAT configuration is a clear hierarchical network, anyway. All what
> EzIP proposes is to make it explicit and universal for improving the
> performance.
>
> 2)  To create a viable hierarchical network with depleted address pool
> like IPv4 was practically an impossible task. Fortunately, the 240/4
> netblock is available because it was "reserved for future use" ever
> since 1981-09, yet no clear application cases could be found. So, this
> is a natural resources that will benefit everyone without reference to
> financial status, although the developing regions can benefit more by
> utilizing it to leap frog out of the current disadvantaged situations.
>
> Hope this explanation makes sense to you.
>
>
> Regards,
>
>
> Abe (2022-11-21 10:29 EST)
>
>
>
>
> On 2022-11-20 17:56, Eric Kuhnke wrote:
> > If I had a dollar for every person who has lived their entire life in
> > a high-income western country (US, Canada, western Europe, etc) and
> > has zero personal experience in developing-nation telecom/ISP
> > operations and their unique operational requirements, yet thinks
> > they've qualified to offer an opinion on it...
> >
> > People should go look at some of the WISPs in the Philippines for an
> > example of ISPs building last and middle mile infrastructure on
> > extremely limited budgets. Or really just about anywhere else where
> > the residential broadband market has households where the entire
> > household monthly income is the equivalent of $500 USD.
> >
> >
> >
> > On Sat, 19 Nov 2022 at 04:59, Mark Tinka  wrote:
> >
> >
> >
> > On 11/19/22 05:50, Abraham Y. Chen wrote:
> >
> > > Dear Owen:
> > >
> > > 1) "... Africa ... They don’t really have a lot of alternatives.
> > ...":
> > > Actually, there is, simple and in plain sight. Please have a
> > look at
> > > the below IETF Draft:
> >
> > It's most amusing, to me, how Africa needs to be told how to be...
> >
> > Some folk just can't help themselves.
> >
> > Mark.
> >
>
>
> --
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com
>

Re: Alternative Re: ipv4/25s and above

[Eric Kuhnke]

If I had a dollar for every person who has lived their entire life in a
high-income western country (US, Canada, western Europe, etc) and has zero
personal experience in developing-nation telecom/ISP operations and their
unique operational requirements, yet thinks they've qualified to offer an
opinion on it...

People should go look at some of the WISPs in the Philippines for an
example of ISPs building last and middle mile infrastructure on extremely
limited budgets. Or really just about anywhere else where the residential
broadband market has households where the entire household monthly income
is the equivalent of $500 USD.



On Sat, 19 Nov 2022 at 04:59, Mark Tinka  wrote:

>
>
> On 11/19/22 05:50, Abraham Y. Chen wrote:
>
> > Dear Owen:
> >
> > 1) "... Africa ... They don’t really have a lot of alternatives. ...":
> > Actually, there is, simple and in plain sight. Please have a look at
> > the below IETF Draft:
>
> It's most amusing, to me, how Africa needs to be told how to be...
>
> Some folk just can't help themselves.
>
> Mark.
>

Looking for historical AS1239 Sprintlink on-net site lists, POP lists, etc

[Eric Kuhnke]

If anyone has on-net site/POP lists for AS1239 that are at least 8-10 years
old or older, I'm wondering if I could get a copy.

Obviously nothing that anybody signed an NDA for, maybe some people out
there have some spreadsheets or text files that were shared by Sprint sales
persons many years ago.

This is related to some information I am gathering to improve documentation
of what will apparently become part of Cogent in the Pacific Northwest,
with T-Mobile's sale of sprint's wireline business.

-Eric

Re: Island-wide power blackout in Puerto Rico

[Eric Kuhnke]

For anybody who wants a perspective into the reachability of netblocks for
a mid sized ISP in PR that isn't Claro (the historical copper wireline
ILEC) or Liberty (the dominant cable TV plant/DOCSIS3 operator), take a
look at:

https://www.peeringdb.com/net/20459

They specialize in gigabit access in condo buildings in the metro San Juan
area.

Gino V runs Aeronet and might be subscribed to NANOG to see this...



On Sun, 18 Sept 2022 at 14:15, Sean Donelan  wrote:

>
> Puerto Rico is experiencing an island-wide power blackout (100%).
>
> Today's (based on yesterday's information) FCC Communication Status Report
> only reports 6.9% of cell towers out of service.  I expect tomorrow's
> report (based on today's information) will be worse.
>
>

Re: Rogers Outage: What do we Know After Two Months?

[Eric Kuhnke]

I did a ctrl-f for "Shaw" in that article and there's zero mention of it.

I realize that the Internet Society is meant to remain neutral and not
comment subjectively on matters of market competition and conglomeration of
telecoms.

It's very concerning to me that the Rogers/Shaw acquisition-merger will
likely be allowed to proceed, even further reducing competition, and
increasing centralization (the opposite of the *decentralization* mentioned
in the article). From the point of view of a Canadian who works primarily
for US-based ISPs these days, at least in the US there's seven or eight
gargantuan multi-billion-dollar sized last mile cable operators. In many
parts of Canada it's just Rogers or Shaw. It's not a good situation at all
for the consumer.





On Mon, 12 Sept 2022 at 07:42, Sean Donelan  wrote:

> Article by Internet Society's Resident Advisor Jim Cowie.
>
>
> Rogers Outage: What do we Know After Two Months?
>
>
> https://pulse.internetsociety.org/blog/rogers-outage-what-do-we-know-after-two-months
>
> September 9, 2022
>
> It’s now been a full two months since Rogers Telecom suffered a nationwide
> Internet outage, leaving tens of millions of Canadians without
> telecommunications services.
>

Re: cogent - Sales practices

[Eric Kuhnke]

I have a morbid curiosity about what the CRM database looks like inside
Cogent, for the stale/cold leads that get passed on to a new junior sales
rep every six months.

The amount of peoples' names/email addresses/phone numbers in there must be
stupendous.

All of this can probably serve as a useful training tool for smaller/mid
sized ISPs with their own outbound sales staff on how not to treat the
potential customers.


On Fri, 5 Aug 2022 at 13:21, Dennis Burgess  wrote:

> So we just got an email from cogent, we have told them time and time again
> to stop calling and stop emailing.  We tell them are good on bandwidth and
> we don’t need any of their services.. They then sent us a e-mail stating
> that they saw us coming though one of their customers networks from us, and
> figured we would want to buy direct instead of going though one of their
> customers. Yes COGENT stated this; well at least one of their sales reps.
> Sounds underhanded, shady, and unethical to me.Just figured I would
> post about it; see if I am making a mountain out of a mole hill 😊
>
>
>
> Here is the e-mail:
>
>
>
> *"Hey (redacted) ,*
>
> *Maybe there is a misunderstanding. (ISP’s name removed) is a cogent
> customer who we provide upstream to.*
>
> *My initial inquiry was to see if it makes sense for Link Technologies to
> be utilizing our network instead of through (ISP’s name removed). That way
> we could be a direct network for you.*
>
> *Would that be at all something that interests you?*
>
>
>
> *Eric Gogerty | Global Account Manager | AS 174*
>
> *Cogent Communications | Minneapolis, MN (United States Of America)|
> www.cogentco.com *
>
> *Contact: 612-217-5506| email: egoge...@cogentco.com
> *
>
> *The Internet, Unleashed!"*
>
>
>
>
>
>
>
>
>
> *[image: LTI-Full_175px]*
>
> *Dennis Burgess*
>
>
> * Mikrotik : **Trainer, Network Associate, Routing Engineer, Wireless
> Engineer, Traffic Control Engineer, Inter-Networking Engineer, Security
> Engineer, Enterprise Wireless Engineer*
>
> *Hurricane Electric: **IPv6 Sage Level*
>
> *Cambium: **ePMP*
>
>
>
> Author of "Learn RouterOS- Second Edition”
>
> *Link Technologies, Inc* -- Mikrotik & WISP Support Services
>
> *Office*: 314-735-0270  Website: http://www.linktechs.net
>
> Create Wireless Coverage’s with www.towercoverage.com
>
> Need MikroTik Cloud Management: https://cloud.linktechs.net
>
> *How did we do today?*
>
> [image: Gold Star]
> [image:
> Green Light]
> [image:
> Yellow Light]
> [image:
> Red Light]
> 
>
>
>

Re: Frontier Dark Fiber

[Eric Kuhnke]

Any regional ILEC spanning at least a few counties in size will have some
amount of inter-CO dark fiber, whether they want to sell it to any 3rd
parties is entirely another question.



On Wed, 3 Aug 2022 at 08:17, Jay Ashworth  wrote:

> I wouldn't have thought that Frontier was able to offer dark fiber, since
> air distribution fan out is all GPON, is it not?
>
> If their fanout was active ethernet it might be a different story but...
>
> Cheers,
> -- jra
>
> On July 13, 2022 7:40:47 AM EDT, Mike Hammett  wrote:
>>
>> I'm looking for a contact at Frontier that can discuss dark fiber.
>>
>> My current account exec says they don't offer it, yet prior conversations
>> with him and a previous SE revealed that they very much did (just didn't
>> have availability on the paths I wanted at the time).
>>
>> Their web site highlights it fairly proudly.
>>
>>
>> I'm aware that availability varies.
>>
>> I'm aware that they likely don't want to sell it.
>>
>>
>>
>> -
>> Mike Hammett
>> Intelligent Computing Solutions 
>> 
>> 
>> 
>> 
>> Midwest Internet Exchange 
>> 
>> 
>> 
>> The Brothers WISP 
>> 
>> 
>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>

Re: FCC Chair sends Letters of Inquiry on Consumer Data Privacy Practices

[Eric Kuhnke]

It would be interesting to see the geolocation data retention and sharing
policy, and what granularity of data is retained and for how long,
contrasting something that is purely a MVNO on some other facilities based
carrier's network, vs a similar SIM card and phone activated directly with
one of the facilities based last mile network operators (TMobile-Sprint,
ATT, Verizon and the smaller regional players like US Cellular).




On Tue, 19 Jul 2022 at 17:04, Sean Donelan  wrote:

> FCC has fixed its website document management system, and has all the
> letters of inquiry posted.
>
>
> In the letters of inquiry, Chairwoman Rosenworcel asks about their
> policies around geolocation data, such as how long geolocation data is
> retained and why and what the current safeguards are to protect this
> sensitive information.  Additionally, the letters probe carriers about
> their processes for sharing subscriber geolocation data with law
> enforcement and other third parties’ data sharing agreements.  Finally,
> the letters ask whether and how consumers are notified when their
> geolocation information is shared with third parties.
>
>
>
> https://www.fcc.gov/document/rosenworcel-probes-mobile-carriers-data-privacy-practices
>
>
> AT&T Services
> Best Buy Health
> Charter Communications
> Comcast
> Consumer Cellular
> C-Spire
> DISH Network
> Google
> H2O Wireless
> Lycamobile
> Mint Mobile
> Red Pocket
> T-Mobile
> U.S. Cellular
> Verizon
>

Re: Frontier Dark Fiber

[Eric Kuhnke]

Unless you are a *significant* sized regional operator in an area that
overlaps with Frontier's ILEC territory is it unlikely in the extreme that
they would want to rent you some dark fiber or issue a quote for it.

Or some kind of very large enterprise customer that Frontier will take
seriously like a Fortune 500 sized manufacturing entity.





On Wed, 13 Jul 2022 at 04:41, Mike Hammett  wrote:

> I'm looking for a contact at Frontier that can discuss dark fiber.
>
> My current account exec says they don't offer it, yet prior conversations
> with him and a previous SE revealed that they very much did (just didn't
> have availability on the paths I wanted at the time).
>
> Their web site highlights it fairly proudly.
>
>
> I'm aware that availability varies.
>
> I'm aware that they likely don't want to sell it.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions 
> 
> 
> 
> 
> Midwest Internet Exchange 
> 
> 
> 
> The Brothers WISP 
> 
> 
>

Re: Rogers Outage Canada

[Eric Kuhnke]

Can we have a discussion with the list admins about a list member appending
a threat of violence to their outbound emails?  Whether serious or not.

Does this person need directions to some local mental healthcare resources?


On Sat, 9 Jul 2022 at 08:48, Keith Medcalf  wrote:

>
> >I can't either, but the reality right now seems to be that 911 calls are
> >failing for anyone on a Rogers cellphone.
>
> This is par for the course.  These people chose to deal with Rogers
> despite knowing the consequences.  It is like if you bought a Rogers
> Snowblower and it did not work.  That would mean that people who bought the
> Rogers Snowblower will not be using it to get rid of the snow that is
> preventing them from leaving their house.
>
> Mutatis mutandis when Rogers is down things that are Rogers dependent will
> not work.
>
> Some people are so retarded it is astonishing!
>
> --
> (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.
>
> >-Original Message-
> >From: NANOG  On Behalf Of
> >Eric Kuhnke
> >Sent: Friday, 8 July, 2022 13:34
> >To: jim deleskie 
> >Cc: NANOG list 
> >Subject: Re: Rogers Outage Canada
> >
> >
> >I have seen anecdotal reports that the mobile network is in a half broken
> >state that phones remain registered to, so a 911 call will attempt and
> >then fail.
> >
> >
> >This is unlike what would happen if you had a US/Canada cellphone with
> >battery power but no SIM card in it that would search for any available
> >network in RF range for a 911 call if needed.
> >
> >
> >On Fri, 8 Jul 2022 at 12:31, jim deleskie  ><mailto:deles...@gmail.com> > wrote:
> >
> >
> >   i cant see BGP taking out SS7.
> >
> >   -jim
> >
> >   On Fri, Jul 8, 2022 at 2:45 PM Snowmobile2004
> >mailto:greenjosh6...@gmail.com> > wrote:
> >
> >
> >   According to Cloudflare Radar
> ><https://radar.cloudflare.com/asn/812?date_filter=last_24_hours> , Rogers
> >BGP announcements spiked massively to levels 536,777% higher than normal
> >(343,601 vs 64 normally) just minutes before the outage. I would not be
> >surprised if this happened to be the culprit.
> >
> >   Regards,
> >   Josh Green
> >
> >   On Fri, Jul 8, 2022 at 2:19 PM Andrew Paolucci via NANOG
> >mailto:nanog@nanog.org> > wrote:
> >
> >
> >   In the early hours of the morning around 2-3am my
> modem
> >got hit with a configuration update that caused a DHCP release that
> >wasn't renewed for about two hours, after rollback the connection was
> >fine for 3 hours before this network wide outage.
> >
> >
> >   Maybe a failed night time update was attempted
> again
> >during office hours, I've heard daytime guys are still WFH and night
> >shift is in building.
> >
> >
> >   I expect we'll never get a real explanation.
> Rogers is
> >notorious for withholding any type of helpful or technical information.
> >
> >
> >   Sent from my inoperable Rogers Mobile via
> emergency eSIM.
> >
> >
> >   Regards,
> >
> >   Andrew Paolucci
> >    Original Message 
> >   On Jul. 8, 2022, 1:48 p.m., Jay Hennigan <
> j...@west.net
> ><mailto:j...@west.net> > wrote:
> >
> >
> >   On 7/8/22 07:44, Robert DeVita wrote: >
> Does anyone
> >have information on a widespread Rogers outage in Canada. I > have
> >customers with multiple sites down. There's discussion on the Outages
> >mailing list. Seems widespread, affecting all services, mobile, voice,
> >Internet. No cause or ETR posted yet. -- Jay Hennigan - j...@west.net
> ><mailto:j...@west.net>  Network Engineering - CCIE #7880 503 897-8550 -
> >WB6RDV
> >
> >
> >
> >   --
> >
> >   Josh Green.
>
>
>
>
>

Re: Rogers Outage Canada

[Eric Kuhnke]

I can't either, but the reality right now seems to be that 911 calls are
failing for anyone on a Rogers cellphone.

I have seen anecdotal reports that the mobile network is in a half broken
state that phones remain registered to, so a 911 call will attempt and then
fail.

This is unlike what would happen if you had a US/Canada cellphone with
battery power but no SIM card in it that would search for any available
network in RF range for a 911 call if needed.

On Fri, 8 Jul 2022 at 12:31, jim deleskie  wrote:

> i cant see BGP taking out SS7.
>
> -jim
>
> On Fri, Jul 8, 2022 at 2:45 PM Snowmobile2004 
> wrote:
>
>> According to Cloudflare Radar
>> , Rogers
>> BGP announcements spiked massively to levels 536,777% higher than normal
>> (343,601 vs 64 normally) just minutes before the outage. I would not be
>> surprised if this happened to be the culprit.
>>
>> Regards,
>> Josh Green
>>
>> On Fri, Jul 8, 2022 at 2:19 PM Andrew Paolucci via NANOG 
>> wrote:
>>
>>> In the early hours of the morning around 2-3am my modem got hit with a
>>> configuration update that caused a DHCP release that wasn't renewed for
>>> about two hours, after rollback the connection was fine for 3 hours before
>>> this network wide outage.
>>>
>>>
>>> Maybe a failed night time update was attempted again during office
>>> hours, I've heard daytime guys are still WFH and night shift is in building.
>>>
>>>
>>> I expect we'll never get a real explanation. Rogers is notorious for
>>> withholding any type of helpful or technical information.
>>>
>>>
>>> Sent from my inoperable Rogers Mobile via emergency eSIM.
>>>
>>>
>>> Regards,
>>>
>>> Andrew Paolucci
>>>  Original Message 
>>> On Jul. 8, 2022, 1:48 p.m., Jay Hennigan < j...@west.net> wrote:
>>>
>>>
>>> On 7/8/22 07:44, Robert DeVita wrote: > Does anyone have information on
>>> a widespread Rogers outage in Canada. I > have customers with multiple
>>> sites down. There's discussion on the Outages mailing list. Seems
>>> widespread, affecting all services, mobile, voice, Internet. No cause or
>>> ETR posted yet. -- Jay Hennigan - j...@west.net Network Engineering -
>>> CCIE #7880 503 897-8550 - WB6RDV
>>>
>>>
>>
>> --
>> *Josh Green.*
>>
>

Re: Rogers Outage Canada

[Eric Kuhnke]

Whatever they did, it has also taken out SS7/PSTN 911 services for many
millions of people.

https://www.cbc.ca/news/business/rogers-outage-cell-mobile-wifi-1.6514373

On Fri, 8 Jul 2022 at 11:44, Snowmobile2004  wrote:

> According to Cloudflare Radar
> , Rogers
> BGP announcements spiked massively to levels 536,777% higher than normal
> (343,601 vs 64 normally) just minutes before the outage. I would not be
> surprised if this happened to be the culprit.
>
> Regards,
> Josh Green
>
> On Fri, Jul 8, 2022 at 2:19 PM Andrew Paolucci via NANOG 
> wrote:
>
>> In the early hours of the morning around 2-3am my modem got hit with a
>> configuration update that caused a DHCP release that wasn't renewed for
>> about two hours, after rollback the connection was fine for 3 hours before
>> this network wide outage.
>>
>>
>> Maybe a failed night time update was attempted again during office hours,
>> I've heard daytime guys are still WFH and night shift is in building.
>>
>>
>> I expect we'll never get a real explanation. Rogers is notorious for
>> withholding any type of helpful or technical information.
>>
>>
>> Sent from my inoperable Rogers Mobile via emergency eSIM.
>>
>>
>> Regards,
>>
>> Andrew Paolucci
>>  Original Message 
>> On Jul. 8, 2022, 1:48 p.m., Jay Hennigan < j...@west.net> wrote:
>>
>>
>> On 7/8/22 07:44, Robert DeVita wrote: > Does anyone have information on a
>> widespread Rogers outage in Canada. I > have customers with multiple sites
>> down. There's discussion on the Outages mailing list. Seems widespread,
>> affecting all services, mobile, voice, Internet. No cause or ETR posted
>> yet. -- Jay Hennigan - j...@west.net Network Engineering - CCIE #7880 503
>> 897-8550 - WB6RDV
>>
>>
>
> --
> *Josh Green.*
>

Re: What say you, nanog re: Starlink vs 5G?

[Eric Kuhnke]

If one watches the activity in the tower/outside plant construction side of
things, Dish recent went into a burst of activity in hiring tower
contractors and signing leases on monopoles, towers and other sites in a
"use it or lose it" necessity to have *some* sort of LTE radios actually
mounted, powered up and on the air, even if there were no customers
connected to the equipment.

They're still doing it as far as I know.

On Mon, 27 Jun 2022 at 12:42, na...@jima.us  wrote:

> Also, to be a little clearer, Dish’s entrance to the cellular world was a
> byproduct of the T-Mobile/Sprint merger. There were understandably some
> concerns with reducing the nationwide competitive landscape down to three
> carriers, so they had to agree to help prop up a replacement competitor.
>
>
>
> *From:* NANOG  *On Behalf Of *
> blakan...@gmail.com
> *Sent:* Sunday, June 26, 2022 00:34
> *To:* Mike Hammett 
> *Cc:* nanog@nanog.org
> *Subject:* Re: What say you, nanog re: Starlink vs 5G?
>
>
>
> Mike Hammett wrote on 6/24/2022 1:22 PM:
>
>
> It's DirecTV that became part of AT&T, but now they're separated again.
>
> Dish Network is building a nation-wide terrestrial mobile network.
> Supposed to be the new #4 provider.
>
>
>
>
> Looks like their plans just hit a snag -
> D.C. court confirms Dish cheated on 5G spectrum bidding, revokes $3.4
> billion in credits
>
> https://www.phonearena.com/news/dish-bidding-5g-spectrum-credits-appeal_id140935
>
> Court decision on the spectrum was decided 6/21:
>
> https://www.cadc.uscourts.gov/internet/opinions.nsf/21AC89289C589E4F85258868004F9B7F/$file/18-1209-1951147.pdf
>
>
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions 
> [image: Image removed by sender.] [image:
> Image removed by sender.]
> [image:
> Image removed by sender.]
> [image:
> Image removed by sender.] 
> Midwest Internet Exchange 
> [image: Image removed by sender.] [image:
> Image removed by sender.]
> [image: Image
> removed by sender.] 
> The Brothers WISP 
> [image: Image removed by sender.]
> [image: Image removed by
> sender.] 
> --
>
> *From: *"Owen DeLong via NANOG"  
> *To: *"Michael Thomas"  
> *Cc: *nanog@nanog.org
> *Sent: *Friday, June 24, 2022 3:14:33 PM
> *Subject: *Re: What say you, nanog re: Starlink vs 5G?
>
>
>
> On Jun 24, 2022, at 13:12 , Michael Thomas  wrote:
>
>
>
>
> On 6/24/22 12:38 PM, Owen DeLong wrote:
>
>
>
> On Jun 24, 2022, at 12:33 , Michael Thomas  wrote:
>
>
> On 6/24/22 9:09 AM, Chris Wright wrote:
>
> The term "5G" among technical circles started vague, became better defined
> over the course of several years, and is becoming vague again. This nuance
> was never well understood in the public eye, nor by mass publications like
> CNN. This is a battle for 12GHz, not 5G.
>
> But is what Starlink saying true or not?
>
> It would be a pity to not have an alternative to incumbent telephants.
>
> Mike
>
> It’s not entirely clear, without knowing the technical details of the
> Starlink modulation scheme whether or not they could successfully share the
> 12Ghz spectrum.
>
> I have no reason to disbelieve their claims.
>
> Frankly, I really don’t think that Dish’s idea of providing 5G mobile
> service from satellites is a particularly good or beneficial one and
> granting them 12Ghz spectrum for this purpose is probably not really in the
> public interest.
>
> I thought they were land based? What I read is that being land based means
> that they can transmit at much higher power.
>
>
>
> I wasn’t aware that Dish had terrestrial facilities. I had forgotten their
> absorption into AT&T.
>
>
>
> So I retract my comments in that regard… They are a traditional telephant
> and I think that terrestrial 5G on 12Ghz is even less useful.
>
>
>
> OTOH, I think Starlink is most definitely an interesting product that does
> provide a clear path to reasonable alternatives to the incumbent telephants.
>
> Especially when you factor in mobility when they get there. No more
> roaming fees, all over the world.
>
>
>
> Yep… Probably one of the reasons DishT&T is trying to fight so hard to
> cause them grief.
>
>
>
> Owen
>
>
>
>
>
>
>

Re: What say you, nanog re: Starlink vs 5G?

[Eric Kuhnke]

Pretty much, with the addition that 10900 MHz to 12700 MHz has for a very
long time been historically reserved for Ku-band one-way and two-way
satellite data services talking to geostationary satellites.

The only thing that SpaceX is doing new here is talking to moving LEO
satellites with their phased array terminals.

Adding a terrestrial transmitter source mounted on towers and with CPEs
that stomps on the same frequencies as the last 20 years of existing two
way VSAT terminals throughout the US seems like a bad idea. Even if you
ignore the existence of Starlink, there's a myriad of low bandwidth but
critical SCADA systems out there and remote locations on ku-band two way
geostationary terminals right now.



On Thu, 23 Jun 2022 at 17:05, William Herrin  wrote:

> On Thu, Jun 23, 2022 at 3:12 PM Michael Thomas  wrote:
> >
> https://www.cnn.com/2022/06/23/tech/spacex-dish-fcc-spectrum-scn/index.html
>
> The article is super light on technical detail but I think what
> they're saying is:
>
> The 12ghz spectrum has been allocated to satellite services which have
> very low power signals at the receiver. Both SpaceX and Dish have
> bands within 12ghz. Dish has asked for permission to use its 12ghz
> spectrum for 5G which has a relatively high power terrestrial signal.
> SpaceX is calling foul: the spectrum was allocated to low power
> satellite signals and high power signals don't play well near low
> power signals... particularly when a bunch of the transmitters are
> cheap consumer equipment that may bleed some of that power into
> adjacent spectrum.
>
> Now someone with more knowledge please tell me how close I got.
>
> Regards,
> Bill Herrin
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
>

Re: cf is down?

[Eric Kuhnke]

Massive spike in consumer facing services reported as broken by
downdetector, almost all are likely cf customers. See downdetector
homepage.


On Mon, Jun 20, 2022, 11:54 PM Dmitry Sherman  wrote:

>
>
>
>
>
>
> *Dmitry Sherman*
>
> Interhost Networks
>
> *T:*
>
> *+972.74.702.9881*
>
> *M:*
>
> *+972.54.318.1182*
>
> *E:*
>
> *dmi...@interhost.net *
>
> *W:*
>
> *interhost.co.il *
>
>
>
> [image: Logo] 
>
>
>

Re: Serious Juniper Hardware EoL Announcements

[Eric Kuhnke]

When I last got pricing on the MX10003 in fall 2021, I was asked if I
wanted pricing on something with exclusively 100GbE interfaces or with
10GbE capability.

I got pricing for both options.

Putting SFP+ 10GbE ports in a router of that total
chassis+RE+linecard+support contract price is an *extremely* costly
proposition on a dollar per port basis.

Would recommend that anyone who thinks they need them to look at ways to
put the 10GbE ports in some other device and attach that to the router.


On Tue, 14 Jun 2022 at 14:09, Brian  wrote:

> From Juniper...
>
> "you are correct that there isn’t a native 10G SFP+ form factor offered
> with the 304.
>
>
>
> QSA adapters are qualified (say for example, Nvidia), and from there it
> can support native 10G Bidi, WDM, etc. The economics per-port, obviously,
> get a little expensive with this approach if a lot of native 10G is needed
> and breakout isn’t an option.
>
>
>
> Thanks!"
>
>
>
> Oh and also I just got the call, Juniper is forcing a Price Hike in July.
>
> On Tue, Jun 14, 2022 at 9:10 AM t...@pelican.org  wrote:
>
>> > The MX204 is pure shocker! Unless the MX304 will come with a
>> > license-based approach to run at MX204 pricing, that is Juniper shooting
>> > themselves in the foot.
>>
>> Unless I'm missing a trick, the MX304 doesn't have an answer to
>> installing DWDM, bidi, or other fancy optics in the SPF+ ports on the
>> MX204.  QSFP+ breakout to 4 x 10G is supported, but only 4 x vanilla 1310
>> optics - you'll need an external OEO solution if you want fancy 10G options.
>>
>> It otherwise seems a nice box on paper, although substantially more
>> expensive than the MX204.
>>
>> Cheers,
>> Tim.
>>
>>
>>

Re: Serious Juniper Hardware EoL Announcements

[Eric Kuhnke]

I think the more common solution for something like that would be to use
one 100GbE port as a trunk on a MX204 or MX304 to a directly adjacent 1U
48-port SFP+ switch in a purely L2 role used as a port expander, with
dwdm/bidi/other unique types of SFP+ optics inserted in that.




On Tue, 14 Jun 2022 at 08:08, t...@pelican.org  wrote:

> > The MX204 is pure shocker! Unless the MX304 will come with a
> > license-based approach to run at MX204 pricing, that is Juniper shooting
> > themselves in the foot.
>
> Unless I'm missing a trick, the MX304 doesn't have an answer to installing
> DWDM, bidi, or other fancy optics in the SPF+ ports on the MX204.  QSFP+
> breakout to 4 x 10G is supported, but only 4 x vanilla 1310 optics - you'll
> need an external OEO solution if you want fancy 10G options.
>
> It otherwise seems a nice box on paper, although substantially more
> expensive than the MX204.
>
> Cheers,
> Tim.
>
>
>

T-Mobile USA network operations

[Eric Kuhnke]

Your data roaming in the Pacific Northwest with the Bell/Telus network is
95% broken at present.

UDP works. QUIC works (such as to use Chrome on a mobile device to do
something with Google). Ordinary port 53 DNS resolution works.

TCP is entirely broken.

After a considerable amount of time, I have given up trying to get this
information across to a first-tier customer support representative, and
have not been successful in escalating it to somebody who actually knows
the difference between TCP and UDP.

Contact me off list if you need additional information.

Re: Aftermarket switches that were manufactured in any sort of quantity?

[Eric Kuhnke]

With all due respect, without sharing NDA protected information about the
specific quantity and model numbers of FS switches I have personal
experience with in a certain network, there are very valid reasons to have
significant concerns about the stability and feature set of the operating
system that ships on them.

There is a *reason* they are abnormally cheap, in exactly the same way that
FS transceivers which are literally the cheapest 1Gbps and 10Gbps OOK
optics you can "Add to cart" and buy online are the cheapest transceivers
you can buy on the market.

But by all means please go ahead and use FS switches for all the layer 2
aggregation needs in your network if you think that they meet your needs.
I'm not stopping you.

If an ISP has a serious enough need for a large quantity of whitebox
switches based on known switch-chip vendors' ASICs I would encourage them
to send staff with experience in the electronics manufacturing industry to
every year's Computex Taipei and speak with the manufacturers in person.





On Thu, 9 Jun 2022 at 11:39, Saku Ytti  wrote:

> On Thu, 9 Jun 2022 at 21:21, Eric Kuhnke  wrote:
>
> > To paraphrase someone else, I would highly recommend that all my
> competition use Fiberstore switches. This is based on direct experience
> with them.
>
> Of course you're not telling anything at all here. I know plenty of
> very happy fs customers, and plenty of disappointed. And you can
> replace fs with anything at all, and it remains true. Nothing of value
> was said.
>
> Very few have statistically useful experience to share just about
> anything, just anecdotes, and every single company regularly has poor
> customer interactions. We regularly extrapolate a lot of information
> from a single anecdote. This is like old men discussing in petrol
> station which car brands are great and which suck, which is always
> near 0 signal information, if you start to apply any type of formality
> to it, like start looking at MOT statistics, you will find, yeah maybe
> there are some signals, maybe Toyota is good, but at the same time you
> will notice, well I can pick really bad Toyota, if I pick specific
> model + model year (next or previous model year of same model might be
> again great).
>
> I have more respect for your competitors' ability to procure than this.
>
> --
>   ++ytti
>

Re: Aftermarket switches that were manufactured in any sort of quantity?

[Eric Kuhnke]

To paraphrase someone else, I would highly recommend that all my
competition use Fiberstore switches. This is based on direct experience
with them.



On Thu, 9 Jun 2022 at 10:03, Rafael Possamai <
rafael.possa...@bluebirdnetwork.com> wrote:

> This may sound bad at first but look into FS.com if you’re in a pinch.
> They may not be seen as the typical true enterprise grade (I don’t know?)
> but you can probably buy a a new one and a new spare for the price of one
> overpriced used switch.
>
>
>
>
>
> *From:* NANOG 
> *On Behalf Of *Drew Weaver
> *Sent:* Thursday, June 9, 2022 11:42 AM
> *To:* 'nanog@nanog.org' 
> *Subject:* Aftermarket switches that were manufactured in any sort of
> quantity?
>
>
>
> Hello,
>
>
>
> We had been purchasing some used 48 port 1BaseT switches /w 6x QSFP28
> ports for around $3000 until about 2021.
>
>
>
> In 2021 the aftermarket pricing went from $3,000 each to $15,000 each.
>
>
>
> Now these particular switches are selling for $20,000 each (and people are
> still buying them[?]…)
>
>
>
> Obviously I cannot pay $20k for a used switch so I am trying to find
> alternatives that perhaps aren’t as rare.
>
>
>
> I’m trying to determine whether this pricing is just based on the model I
> am trying to buy or if it is basically every switch from every MFG.
>
>
>
> Just trying to see if anyone else has had any luck getting any hardware at
> around a fair price lately?
>
>
>
> I’m aware of the macro-economic environment, inflation, chip shortages,
> etc.. Just looking for another option.
>
>
>
> Thanks,
>
> -Drew
>
>
>

Re: FCC proposes higher speed goals (100/20 Mbps) for USF providers

[Eric Kuhnke]

At this point I don't think we can reasonably expect something like an
online purchased game from the Microsoft store for somebody's new Xbox
Series X to *not* be a 150GB download. There's a number of games out there
like that. And if people only have 25 to 50Mbps downstream they absolutely
will complain that it takes way too long.

We may not conceptually agree with it but that is certainly what the game
developers are doing and publishing.



On Mon, 6 Jun 2022 at 12:05, Paul Timmins  wrote:

> How many times have I seen an installer only download the parts it needs
> vs just reinstall the next version right over top of the existing
> version? I know stuff like xplane seems to do a comparison of file
> signatures and only downloads the changed parts for the updates between
> whatever version I have and whatever version is current now, but I'd
> imagine a lot of installers these days just take advantage of the fact
> the user has a super fast connection and they don't have to care about
> shipping the entire new installer just to run an update.
>
> Not to mention whatever amounts of shovelware come with a few megabyte
> print driver for a modern printer/scanner/copier. Let's just include a
> copy of McAfee endpoint protection in this java update in case the user
> opts into selecting that as an option during install? etc.
>
> -Paul
>
> On 6/6/22 14:24, Chris Adams wrote:
> > Once upon a time, Michael Thomas  said:
> >> I meant downloads as in gigantic games. If you give them more
> >> bandwidth it just encourages the game makes to build bigger game
> >> downloads.
> > I don't buy that - users are still constrained on storage, especially on
> > consoles.
>

Re: Anyone on list from Zayo about possible router issue?

[Eric Kuhnke]

There was a massive Zayo-maintenance-caused inter city fiber cut in the
Pacific Northwest yesterday. I can't say more but I'm sure if you're a
direct Zayo customer on the affected routes you can get *some* sort of RFO.



On Fri, 3 Jun 2022 at 12:59, David Gianndrea  wrote:

> Hello all,
>
>
>
> I’m tracking down an VPN issue for a user whose path to us crosses a Zayo
> router ( ae14.cs3.ord2.us.zip.zayo.com ) which is showing a crazy amount
> of packet loss in the 90% range. Is there Anyone on list from Zayo who
> could confirm or deny what I’m seeing?
>
>
>
> Thanks
>
>
>
> David Gianndrea
>
> Senior Network Engineer
>
> Milner, Inc.
>
>
>
> Email:   dgiannd...@milner.com
>
> Web: www.milner.com
>
>
>
>
>

Re: FCC proposes higher speed goals (100/20 Mbps) for USF providers

[Eric Kuhnke]

This is going to be very painful and difficult for a number of DOCSIS3
operators, including some of the largest ISPs in the USA with
multi-millions of subscribers with tons of legacy coax plant that have no
intention of ever changing the RF channel setup and downstream/upstream
asymmetric bandwidth allocation to provide more than 15-20Mbps upstream per
home.





On Thu, 26 May 2022 at 16:59, Jeff Shultz  wrote:

> I think we have a winner here - we don't necessarily need 1G down, but we
> do need to get the upload speeds up to symmetrical 50/50, 100/100 etc...
> there are enough people putting in HD security cameras and the like that
> upstream speeds are beginning to be an issue.
>
> On Tue, May 24, 2022 at 4:37 AM David Bass  wrote:
>
>> The real problem most users experience isn’t that they have a gig, or
>> even 100Mb of available download bandwidth…it’s that they infrequently are
>> able to use that full bandwidth due to massive over subscription .
>>
>> The other issue is the minimal upload speed.  It’s fairly easy to consume
>> the 10Mb that you’re typically getting as a residential customer.  Even
>> “business class” broadband service has a pretty poor upload bandwidth
>> limit.
>>
>> We are a pretty high usage family, and 100/10 has been adequate, but
>> there’s been times when we are pegged at the 10 Mb upload limit, and we
>> start to see issues.
>>
>> I’d say 25/5 is a minimum for a single person.
>>
>> Would 1 gig be nice…yeah as long as the upload speed is dramatically
>> increased as part of that.  We would rarely use it, but that would likely
>> be sufficient for a long time.  I wouldn’t pay for the extra at this point
>> though.
>>
>> On Mon, May 23, 2022 at 8:20 PM Sean Donelan  wrote:
>>
>>>
>>> Remember, this rulemaking is for 1.1 million locations with the "worst"
>>> return on investment. The end of the tail of the long tail.  Rural and
>>> tribal locations which aren't profitable to provide higher speed
>>> broadband.
>>>
>>> These locations have very low customer density, and difficult to serve.
>>>
>>> After the Sandwich Isles Communications scandal, gold-plated proposals
>>> will be viewed with skepticism.  While a proposal may have a lower total
>>> cost of ownership over decades, the business case is the cheapest for
>>> the first 10 years of subsidies.  [massive over-simplification]
>>>
>>> Historically, these projects have lack of timely completion (abandoned,
>>> incomplete), and bad (overly optimistic?) budgeting.
>>>
>>
>
> --
> Jeff Shultz
>
>
> Like us on Social Media for News, Promotions, and other information!!
>
> [image:
> https://www.instagram.com/sctc_sctc/]
> 
> 
> 
>
>
>
>
>
>
>
>  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. 
>

Looking for an Amazon Cloudfront contact

[Eric Kuhnke]

It looks like I may have a range of recently put into use residential
symmetric gigabit last mile IP space that's being filtered/blocked at the
application level.

Please contact me off-list.

Re: RFC 9225 - Software Defects Considered Harmful

[Eric Kuhnke]

If there's a bug in an ISP's implementation of RFC2549 carrier 'equipment',
is that considered a software bug, hardware, or subject of ornithological
research?



On Fri, 1 Apr 2022 at 10:40, Job Snijders via NANOG  wrote:

> Hi all,
>
> It's super official now: no more software bugs in networking gear.
> Sorry it took so long to document what the best current practise is!
>
> Kind regards,
>
> Job / Chris / Remco
>
> - Forwarded message from rfc-edi...@rfc-editor.org -
> Date: Fri,  1 Apr 2022 10:17:37 -0700 (PDT)
> From: rfc-edi...@rfc-editor.org
> To: ietf-annou...@ietf.org, rfc-d...@rfc-editor.org
> Cc: drafts-update-...@iana.org, rfc-edi...@rfc-editor.org
> Subject: RFC 9225 on Software Defects Considered Harmful
>
> A new Request for Comments is now available in online RFC libraries.
>
> RFC 9225
>
> Title:  Software Defects Considered Harmful
> Author: J. Snijders,
> C. Morrow,
> R. van Mook
> Status: Informational
> Stream: Independent
> Date:   1 April 2022
> Mailbox:j...@fastly.com,
> morr...@ops-netman.net,
> re...@asteroidhq.com
> Pages:  6
> Updates/Obsoletes/SeeAlso:   None
>
> I-D Tag:draft-dont-write-bugs-00.txt
>
> URL:https://www.rfc-editor.org/info/rfc9225
> DOI:10.17487/RFC9225
>
> This document discourages the practice of introducing software
> defects in general and in network protocol implementations
> specifically.  Software defects are one of the largest cost drivers
> for the networking industry.  This document is intended to clarify
> the best current practice in this regard.
>
>
> INFORMATIONAL: This memo provides information for the Internet community.
> It does not specify an Internet standard of any kind. Distribution of
> this memo is unlimited.
>
> This announcement is sent to the IETF-Announce and rfc-dist lists.
> To subscribe or unsubscribe, see
>   https://www.ietf.org/mailman/listinfo/ietf-announce
>   https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
>
> For searching the RFC series, see https://www.rfc-editor.org/search
> For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk
>
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
>
> The RFC Editor Team
> Association Management Solutions, LLC
>
> ___
> IETF-Announce mailing list
> ietf-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce
>
> - End forwarded message -
>

Re: Cogent ...

[Eric Kuhnke]

I have a morbid curiosity what their CRM system looks like, and how many
entries are in it and what their internal notes/work flow looks like.

This opinion is formed from the external perspective of being a person who
is a very cold sales lead and yet continues to be occasionally called by a
new sales person every 4 to 6 months.


On Thu, 31 Mar 2022 at 08:39, Laura Smith via NANOG  wrote:

> Hmmm
>
> Spring has sprung and the waft of drivel from a new season Cogent
> salesdroid filled my telephone earpiece today.
>
> I've never liked the Cogent way of business and my understanding of their
> IP transit is that it falls into the "cheap for a reason" category.
>
> However, perhaps someone would care to elaborate (either on or off-list)
> what the deal is with the requirement to sign NDAs with Cogent before
> they'll discuss things like why they still charge for BGP, or indeed any
> other technical or pricing matters. Seems weird ?!?
>
> Laura
>

Re: ISP data collection from home routers

[Eric Kuhnke]

yes, because otherwise the contention (it's a shared access media, after
all) and RF channel bonding/allocation wouldn't work. Configuration depends
on what the exact CMTS configuration is on your last mile coax segment.

however it's also possible to have the cable MSO push an update to
cablemodems which locks out a read-only diagnostics/info page that would
otherwise be available.



On Fri, 25 Mar 2022 at 13:47, Michael Thomas  wrote:

>
> On 3/24/22 12:53 PM, Tom Beecher wrote:
> > You don't even have to use their equipment. My provider at home is
> > Charter / Spectrum. I own my own cable modem  / router ,they have no
> > equipment in my home. Their privacy policy is pretty standard.
> > Essentially :
> > - Anything they can see that I transmit they will collect.
> > - Anything they can see when I use their apps , even if I'm not on
> > their network, they will collect.
> > - They will use that information for their technical and business
> > reasons, whatever they want.
> > - I am very limited in what I can request that they don't collect or use.
> >
> > None of this is new in the US. I think more people care about
> > this than we think, but people don't really have an option to vote
> > with their wallets.
>
> Even if you own your modem, the DOCSIS specs require that it be
> completely controlled by the MSO, right?
>
> Mike
>
>
>

Re: WP: Russian military behind hack of satellite communication devices

[Eric Kuhnke]

Point to multipoint / TDMA contended access VSAT hub and CPE networks are
well known for not having much security. In many setups the remote CPE
modems, which are built from a fairly cheap BOM of hardware, implicitly
trust the hub linecard. Have seen this with 3 different vendors' platforms.

I'd be willing to bet that this was either a malicious firmware push that
was applied to the CPEs without proper authentication methods being in
place, such as CPEs being able to verify a crypto key signed firmware
signature, or a configuration file pushed to the CPEs that knocked them off
the network with incorrect RF/channel/modulation/timing parameters.

Note that the Viasat KA-SAT terminals are at the very lower end of the
market for contended access (64:1 or more) consumer/small business grade
geostationary VSAT. Which is why it sort of makes sense that a lot of them
were used for low data rate SCADA for wind farms and such.




On Thu, 24 Mar 2022 at 20:48, Sean Donelan  wrote:

>
> Not yet official, but the U.S. intelligence community seems to continue
> its rapid release of intelligence.  I think everyone was expecting it,
> especially since Viasat executives declined to say it earlier this week at
> the SATCOM 2022 conference.
>
>
>
>
> https://www.washingtonpost.com/national-security/2022/03/24/russian-military-behind-hack-satellite-communication-devices-ukraine-wars-outset-us-officials-say/
> By Ellen Nakashima
> Today at 10:25 p.m. EDT
>
> U.S. intelligence analysts have concluded that Russian military spy
> hackers were behind a cyberattack on a satellite broadband service that
> disrupted Ukraine’s military communications at the start of the war last
> month, according to U.S. officials familiar with the matter.
>
> The U.S. government, however, has not announced its conclusion publicly.
>
> [...]
>
> The modems were part of Viasat’s European satellite network, KA-SAT. The
> company uses distributors in Europe to sell Internet service, which relies
> on modems, to customers. The company is shipping new modems to the
> distributors so they can get them to affected customers, the official
> said.
>

Re: "Permanent" DST

[Eric Kuhnke]

That is true but at present everything business related in BC has a clear
expectation of being in the same time zone as WA/OR/CA, and AB matches US
Mountain time.

On Tue, 15 Mar 2022 at 13:35, Paul Ebersman  wrote:

> eric> If Canada doesn't do the same thing at the same time, it'll be a
> eric> real hassle, dealing with a change from -8 to -7 crossing the
> eric> border between BC and WA, for instance. It has to be done
> eric> consistently throughout North America.
>
> You must not have ever dealt with Indiana, where it was DST or not by
> choice per county. It wasn't quite the cluster***k you'd think.
>
>

Re: "Permanent" DST

[Eric Kuhnke]

If Canada doesn't do the same thing at the same time, it'll be a real
hassle, dealing with a change from -8 to -7 crossing the border between BC
and WA, for instance. It has to be done consistently throughout North
America.

On Tue, 15 Mar 2022 at 12:35, Jay R. Ashworth  wrote:

> The bill is "permanently move all US time zones one hour earlier (-8 thru
> -5 is
> replaced permanently with -7 thru -4).
>
> They are *calling it* "permanent DST", but that's not really what's
> happening,
> in my engineering appraisal.  Or my geopolitical one, but I don't lay
> claim
> to professional opinions there.
> -- jra
>
> - Original Message -
> > From: "Mel Beckman" 
> > To: "jra" 
> > Cc: "nanog@nanog.org list" 
> > Sent: Tuesday, March 15, 2022 3:19:11 PM
> > Subject: Re: "Permanent" DST
>
> > I don’t follow why cancelling DST has the effect of moving the US fifteen
> > degrees to the east. Also, your subject line reads “permanent DST”, but
> from
> > your language the bill will be permanent standard time.
> >
> > I haven’t read the bill, but I’m hoping you can explain your position
> more
> > clearly.
> >
> > -mel via cell
> >
> >> On Mar 15, 2022, at 3:13 PM, Jay R. Ashworth  wrote:
> >>
> >> In a unanimous vote today, the US Senate approved a bill which would
> >>
> >> 1) Cancel DST permanently, and
> >> 2) Move every square inch of US territory 15 degrees to the east.
> >>
> >> My opinion of this ought to be obvious from my rhetoric.  Hopefully, it
> will
> >> fail, because it's likely to be the end of rational time worldwide, and
> even
> >> if you do log in UTC, it will still make your life difficult.
> >>
> >> I'm poleaxed; I can't even decide which grounds to scream about this
> on...
> >>
> >> Hopefully, the House or the White House will be more coherent in their
> >> decision on this engineering construct.
> >>
> >> Cheers,
> >> -- jra
> >>
> >> --
> >> Jay R. Ashworth  Baylink
> j...@baylink.com
> >> Designer The Things I Think
>  RFC 2100
> >> Ashworth & Associates   http://www.bcp38.info  2000 Land
> Rover DII
> > > St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727
> 647 1274
>
> --
> Jay R. Ashworth  Baylink
> j...@baylink.com
> Designer The Things I Think   RFC
> 2100
> Ashworth & Associates   http://www.bcp38.info  2000 Land
> Rover DII
> St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647
> 1274
>

Re: Russia attempts mandating installation of root CA on clients for TLS MITM

[Eric Kuhnke]

Clarification, Google Chrome has its own root CA revocation/CRL program. It
does still rely on the operating system root CA trust store.

Using a typical intranet/RFC1918 IP space environment as an example, as you
might see in any $BIGCORP, if you install your own choice of root CA in the
Windows 10 root CA trust store, Chrome's TLS1.2/TLS1.3 access to internal
resources that are https only will work flawlessly without any security
warnings. Very normal configuration these days. Used for things like DLP in
banking/corporate environments or places where the gateway between internal
IP space and the public world has a firewall in place with MITM ability for
all TLS traffic.

On any windows 10 system with local admin privileges you can manually find
this by opening MMC, go to add/remove snap-ins, select the certificates
(local computer) snap-in, left side menu browse to trusted root
certificates.



On Fri, 11 Mar 2022 at 10:48, Mu  wrote:

> >Mozilla is the only browser vendor these days that maintains its own
> independent root CA storage for the browser. Chrome, Chromium, Safari,
> Edge, IE etc all use whatever root CAs are trusted by the operating system.
> If they can get Windows 10 client PCs pushed to retail with an image that
> includes their CA...
>
> Google Chrome has it's own root program, and all vendors have been reliant
> on Mozilla's setup for some time. They don't just blindly trust the OS.
>
>
> --- Original Message ---
> On Friday, March 11th, 2022 at 1:34 PM, Eric Kuhnke 
> wrote:
>
> Considering that 99% of non-technical end users of windows, macos,
> android, ios client devices *have no idea what a root CA is,* if an
> authoritarian regime can mandate the installation of a government-run root
> CA in the operating system CA trust store of all new devices sold at
> retail, as equipment is discarded/upgraded/replaced incrementally over a
> period of years, they could eventually have the capability of MITM of a
> significant portion of traffic.
>
> Presumably with Apple ending shipment of new MacOS devices to Russia and
> retail sales of new devices, this wouldn't be so much of an issue with
> MacOS. The process of re-imaging a modified MacOS install .DMG onto a
> "blank" macbook air or similar with a new root CA included would be non
> trivial, and hopefully might be impossible due to crypto signature required
> for a legit MacOS bootable install image.
>
> Mozilla is the only browser vendor these days that maintains its own
> independen root CA storage for the browser. Chrome, Chromium, Safari, Edge,
> IE etc all use whatever root CAs are trusted by the operating system. If
> they can get Windows 10 client PCs pushed to retail with an image that
> includes their CA...
>
>
>
>
>
>
> On Thu, 10 Mar 2022 at 18:27, Dario Ciccarone (dciccaro) via NANOG <
> nanog@nanog.org> wrote:
>
>> I think the point Eric was trying to make is that while, indeed, the
>> initial, stated goal might be to be able to issue certificates to replace
>> those expired or expiring, there's just a jump/skip/hop to force
>> installation of this root CA certificate in all browsers, or for Russia to
>> block downloads of Firefox/Chrome from outside the Federation, and instead
>> distribute versions which would already include this CA's certificate. And
>> then MITM the whole population without their knowledge or approval.
>>
>> GIVEN: savvy users might know how to delete the certificate, or others
>> may teach them how, and how to download other CA's certificates (if the
>> government was to ship only this certificate with the browser). Cat and
>> mouse game. The North Korean and Chinese governments have been doing these
>> kind of shenanigans for a long time - I am sure Russia could copy their
>> model. And considering the tight media control they’re already exercising,
>> I don't think it is crazy or paranoid to think Internet will be next. They
>> seem to be already going down that path.
>>
>> PS: opinions and statements, like the above, are my very own personal
>> take or opinion. Nothing I say should be interpreted to be my employer's
>> position, nor be supported by my employer.
>>
>> On 3/10/22, 7:38 PM, "NANOG on behalf of Sean Donelan"
>> 
>> wrote:
>>
>> On Thu, 10 Mar 2022, Eric Kuhnke wrote:
>> > I think we'll see a lot more of this from authoritarian regimes in the
>> > future. For anyone unfamiliar with their existing distributed DPI
>> > architecture, google "Russia SORM".
>>
>> Many nation's have a government CA.
>>
>> The United States Government has its Federal Publi

Re: Russia attempts mandating installation of root CA on clients for TLS MITM

[Eric Kuhnke]

Considering that 99% of non-technical end users of windows, macos, android,
ios client devices *have no idea what a root CA is,* if an authoritarian
regime can mandate the installation of a government-run root CA in the
operating system CA trust store of all new devices sold at retail, as
equipment is discarded/upgraded/replaced incrementally over a period of
years, they could eventually have the capability of MITM of a significant
portion of traffic.

Presumably with Apple ending shipment of new MacOS devices to Russia and
retail sales of new devices, this wouldn't be so much of an issue with
MacOS.  The process of re-imaging a modified MacOS install .DMG onto a
"blank" macbook air or similar with a new root CA included would be non
trivial, and hopefully might be impossible due to crypto signature required
for a legit MacOS bootable install image.

Mozilla is the only browser vendor these days that maintains its own
independen root CA storage for the browser. Chrome, Chromium, Safari, Edge,
IE etc all use whatever root CAs are trusted by the operating system. If
they can get Windows 10 client PCs pushed to retail with an image that
includes their CA...






On Thu, 10 Mar 2022 at 18:27, Dario Ciccarone (dciccaro) via NANOG <
nanog@nanog.org> wrote:

> I think the point Eric was trying to make is that while, indeed, the
> initial, stated goal might be to be able to issue certificates to replace
> those expired or expiring, there's just a jump/skip/hop to force
> installation of this root CA certificate in all browsers, or for Russia to
> block downloads of Firefox/Chrome from outside the Federation, and instead
> distribute versions which would already include this CA's certificate. And
> then MITM the whole population without their knowledge or approval.
>
> GIVEN: savvy users might know how to delete the certificate, or others may
> teach them how, and how to download other CA's certificates (if the
> government was to ship only this certificate with the browser). Cat and
> mouse game. The North Korean and Chinese governments have been doing these
> kind of shenanigans for a long time - I am sure Russia could copy their
> model. And considering the tight media control they’re already exercising,
> I don't think it is crazy or paranoid to think Internet will be next. They
> seem to be already going down that path.
>
> PS: opinions and statements, like the above, are my very own personal take
> or opinion. Nothing I say should be interpreted to be my employer's
> position, nor be supported by my employer.
>
> On 3/10/22, 7:38 PM, "NANOG on behalf of Sean Donelan"
> 
> wrote:
>
> On Thu, 10 Mar 2022, Eric Kuhnke wrote:
> > I think we'll see a lot more of this from authoritarian regimes in
> the
> > future. For anyone unfamiliar with their existing distributed DPI
> > architecture, google "Russia SORM".
>
> Many nation's have a government CA.
>
> The United States Government has its Federal Public Key
> Infrastructure,
> and Federal Bridge CA.
>
> https://playbooks.idmanagement.gov/fpki/ca/
>
> If you use DOD CAC ID's or FCEB PIV cards or other federal programs,
> your
> computer needs to have the FPKI CA's.  You don't need the FPKI CA's
> for
> other purposes.
>
> Some countries CA's issue for citizen and business certificates.
>
>
> While X509 allows you to specify different CA's for different
> purposes,
> since the days of Netscape, browsers trust hundreds of root or bridged
> CA
> in its trust repository for anything.
>
> Neither commercial or government CA's are inherently more (or less)
> trustworthy.  There have been trouble with CA's of all types.
>
> A X509 certificate is a big integer number, in a fancy wrapper.  Its
> not a
> magical object.
>
>

Russia attempts mandating installation of root CA on clients for TLS MITM

[Eric Kuhnke]

https://bugzilla.mozilla.org/show_bug.cgi?id=1758773

I think we'll see a lot more of this from authoritarian regimes in the
future. For anyone unfamiliar with their existing distributed DPI
architecture, google "Russia SORM".

Re: Starlink terminals deployed in Ukraine

[Eric Kuhnke]

I'm aware of the qualifications and level of knowledge in network
security/cryptography that they hire for positions in Redmond at Starlink
R&D. They are quite picky about who they hire.

Highly doubt that anything that a 3rd party can do from outside of SpaceX's
network is going to gain admin control over Starlink satellites. Attempt to
jam them at the RF level, maybe.



On Wed, 2 Mar 2022 at 15:40, Mike  wrote:

> You guys are missing the obvious. Russia isn't going to attack starlink in
> space, they are going to take over it's command and control functions and
> deorbit the entire constellation without firing a shot. Same for China and
> N. Korea, which both already have ample motivation already to go after
> starlink because of the existential threat to the iron fisted control they
> exert over their populace and the free flow of information. So while musk
> may be able to fly 50 at a time and has his own launch capability, if the
> command and control facilities are hijacked, musk will run out of money
> putting it all back together.
>
>
>
> On 3/2/22 1:28 PM, Scott McGrath wrote:
>
> The Russians have several ASAT systems not all of them are ground based.
> Remember they also have that grappler which locks onto satellites and
> destroys them. I think this conflict will be the first one where some
> of the battles will be fought in orbit ie the ultimate ‘high ground’ the
> NATO countries have kept to the UN treaties on not militarizing space.
>  Other countries well not so much
>
> On Wed, Mar 2, 2022 at 12:35 PM Valdis Klētnieks 
> wrote:
>
>> On Wed, 02 Mar 2022 08:51:05 -0500, Dorn Hetzel said:
>>
>> > Yeah, if Russia needs one 1st stage booster for every bird they kill,
>> and
>> > SpaceX needs one 1st stage booster for every 50 they put up  Yes,
>> > Russia is bigger than SpaceX, but that's a tremendous ratio.
>>
>> Plus  the asymmetry is even worse than that
>>
>> Elon can use that *same* first stage booster to launch *another* 50
>> next week, while the Russians need to get a *new* booster for shooting
>> down the next bird.
>>
>> That's the *real* game changer in what SpaceX is doing
>>
>

Starlink terminal visual camouflage tests vs improvised fabric materials

[Eric Kuhnke]

I have just completed some very unscientific tests of DIY camouflage
materials vs a starlink terminal.

Obviously there is a lot of possible discussion that is possible about
spectrum analyzers, direction finding, jammers, etc within the context of
what's going on in Ukraine right now. All very valid concerns.

That said, there's also some DIY possibilities for making a starlink
terminal much less noticeable from the air or casual observation, such as
if installed on top of a mid rise apartment building in any Ukrainian city.
I would wager that the ratio of portable Ku/Ka-band spectrum analyzers with
horn antennas to invasion foot soldiers/armored vehicle soldiers is rather
low at present.

Terminal is the same as the following RIPE atlas probe location:
https://atlas.ripe.net/probes/1001821

Terminal is a v1 from Jan. 2021.

Fabrics have been draped flat over the Starlink terminal. What effect this
will have vs. suspended in the air a meter or so above it on some sort of
improvised framework is a question I can't really answer right now (if we
have any inflatable or fabric radome specialists here, please chime in).

Average of multiple speedtest.net CLI runs to server ID 11329 in Seattle.
In general any of the well-peered speedtest.net servers in Seattle have the
same results, the bottleneck is the starlink last-mile performance at any
given point in time, and not any terrestrial network factors.


*Baseline terminal with no material above it. I do have a slight tree
obstruction in 1/12th of its field of view to the northeast.*
152.48 Mbps down x 8.23 Mbps up, 3.17% loss
(note this averages more like 0.43% loss over 3 to 10 hour periods to its
gateway in Seattle, I believe the loss during the particular time period
this data was gathered to be an aberration).

*Tent rain fly, synthetic nylon material, dry*
162.02 Mbps down x 7.14 Mbps up, 1.43% loss

*Two layers cotton bed sheet, doubled over on itself, thoroughly soaked in
tap water*
55.79 Mbps down x 3.70 Mbps up, 0.77% loss

*One layer cotton bed sheet, dry*
158.78 Mbps down x 7.16 Mbps up, 0.9% loss

*Two layers thin polypropylene tarpaulin, doubled over on itself,
approximately simulating the thickness of a single layer heavy duty tarp.*
152.77 Mbps down x 9.70 Mbps up, 1.41% loss

Re: Starlink terminals deployed in Ukraine

[Eric Kuhnke]

As of right now >90% of the starlink satellites in orbit function in what
we would call a bent pipe topology, where a moving LEO satellite at any
given moment in time needs to be simultaneously in view of a starlink-run
earth station and the CPE.

They have been launching satellites with sat-to-sat laser links but such
architecture is by no means fully operational yet. It does appear to be the
intended architecture in the long term, to enable several hops of satellite
in between a CPE and a starlink-run earth station.

My best theory would be that this is using existing starlink earth stations
in Slovakia or Poland. They may have accelerated the commissioning of some
of the newest ones.





On Mon, 28 Feb 2022 at 16:36, Jay Hennigan  wrote:

> On 2/28/22 16:17, Michael Thomas wrote:
>
> > As a practical matter how does this help? You need to have base
> > stations/dishes, right? Can they be beefy ones that can pump out
> > gigabytes that would be capable of backfilling the load? Or would it
> > need to be multiple in parallel? Wouldn't that bandwidth be constrained
> > by the number of visible satellites in the constellation? I wonder if
> > they've ever even tested it with feeding into an internet facing router.
> > Could tables on the satellites explode?
>
> If there aren't fixed Internet-connected earth stations line-of-sight to
> the satellite that's serving the remote terminal, Starlink will relay
> satellite-to-satellite until a path to an Internet-connected earth
> station is in reach.
>
>  From the linked article:
>
> "Musk has previously stressed Starlink’s flexibility of Starlink in
> providing internet service. In September, Musk talked about how the
> company would use links between the satellites to create a network that
> could provide service even in countries that prohibit SpaceX from
> installing ground infrastructure for distribution.
>
> As for government regulators who want to block Starlink from using that
> capability, Musk had a simple answer.
>
> “They can shake their fist at the sky,” Musk said."
>
> --
> Jay Hennigan - j...@west.net
> Network Engineering - CCIE #7880
> 503 897-8550 - WB6RDV
>

Re: Russian aligned ASNs?

[Eric Kuhnke]

The four LTE (3GPP rev-whatever) based networks in Afghanistan are all
still operational. Roshan, AWCC, MTN, Etisalat.

In .AF the line between ISP and MNO is very blurry since 98% of internet
using customers do not have fixed line service at home or office and use a
mobile network instead.

These have developed a great deal of institutional knowledge operating in
very difficult conditions. The major change now is that the Taliban is no
longer burning tower site cabinets/shelters.



On Fri, 25 Feb 2022 at 12:20, scott  wrote:

>
> > My friend just got a phone call.  Electricity, cell phones and
> > internet are all functional at this time.
>
> --
>
>
> Just imagine what it must be like trying to keep those IP networks
> functional at a time like this.  Configuring routers while under fire...
> Those engineers should get some kind of award...
>
> scott
>
>