Re: Steve Bellovin retires

[Patrick Gilmore]

End of an era.

Thank you for all you did, Steve. And I know you are not done!

-- 
TTFN,
patrick

> On May 1, 2024, at 04:09, Jay Ashworth  wrote:
> 
> Steve Bellovin retires:
> 
> https://mastodon.lawprofs.org/@SteveBellovin/112362015712050310
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Networks ignoring prepends?

[Patrick W. Gilmore]

> The Internet is lying to itself, and that’s not a situation that can persist 
> forever.

I am not sure I agree.

First, prepends are a suggestion. Perhaps a request. It has never (or at least 
not for the 3 decades I’ve been doing this) been a guarantee. In the situation 
below, perhaps the 5K mile backup path is through a provider who pays 
Centurylink (Lumen?). Standard practice is to localpref your customers up, 
which makes prepends irrelevant. Why would anyone expect different behavior?

As for hiding hops, that is not lying. What happens inside my network is my 
business. If I give the world some info, say with in-addrs on hops, that’s 
fine. If I do not, I am not “lying”. This is perfectly sustainable, nothing 
will break (IMHO). In fact, I would argue without tools like MPLS, the Internet 
would have broken a long time ago.

-- 
TTFN,
patrick

> On Jan 22, 2024, at 08:13, Mel Beckman  wrote:
> 
> Prepend contraction is becoming more common. You can’t really stop providers 
> from doing it, and it reduces BGP table size, which I’ve heard as a secondary 
> rationale. I’d love to see the statistics on that though.
> 
> BGP Communities seem to be the only alternative, and that limits your 
> engineering reach to mostly immediate peers.
> 
> Another problem is providers that hide multiple router hops inside MPLS, 
> which appears as a single ip hop in traceroutes, making it impossible to know 
> the truth path geographically. 
> 
> The Internet is lying to itself, and that’s not a situation that can persist 
> forever.
> 
> -mel via cell
> 
>> On Jan 22, 2024, at 4:52 AM, William Herrin  wrote:
>> 
>> Howdy,
>> 
>> Does anyone have suggestions for dealing with networks who ignore my
>> BGP route prepends?
>> 
>> I have a primary ingress with no prepends and then several distant
>> backups with multiple prepends of my own AS number. My intention, of
>> course, is that folks take the short path to me whenever it's
>> reachable.
>> 
>> A few years ago, Comcast decided it would prefer the 5000 mile,
>> five-prepend loop to the short 10 mile path. I was able to cure that
>> with a community telling my ISP along that path to not advertise my
>> route to Comcast. Today it's Centurylink. Same story; they'd rather
>> send the packets 5000 miles to the other coast and back than 10 miles
>> across town. I know they have the correct route because when I
>> withdraw the distant ones entirely, they see and use it. But this time
>> it's not just one path; they prefer any other path except the one I
>> want them to use. And Centurylink is not a peer of those ISPs, so
>> there doesn't appear to be any community I can use to tell them not to
>> use the route.
>> 
>> I hate to litter the table with a batch of more-specifics that only
>> originate from the short, preferred link but I'm at a loss as to what
>> else to do.
>> 
>> Advice would be most welcome.
>> 
>> Regards,
>> Bill Herrin
>> 
>> --
>> William Herrin
>> b...@herrin.us
>> https://bill.herrin.us/

Re: cogent spamming directly from ARIN records?

[Patrick W. Gilmore]

Has anyone replied?

If this is a peering request, not sure that is a bad use of the AS contact info.

If it is a sales pitch, then yeah, that’s a problem.

-- 
TTFN,
patrick

> On Oct 2, 2023, at 14:58, Tim Burke  wrote:
> 
> Hurricane has been doing the same thing lately... but their schtick is to say 
> that "we are seeing a significant amount of hops in your AS path and wanted 
> to know if you are open to resolve this issue".
> 
> complia...@arin.net is about all that can be done, other than public shaming! 
> 
> Other outfits have been spamming using the nanog attendees list, but I guess 
> that’s not as bad as the continued scraping of ARIN records, so I won't call 
> them out... yet, at least. 
> 
> -Original Message-
> From: NANOG  On Behalf Of Mel Beckman
> Sent: Monday, October 2, 2023 10:28 AM
> To: nanog list 
> Subject: cogent spamming directly from ARIN records?
> 
> 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: Spectrum (legacy TWC) Infrastructure - Contact Off List (Patrick Garner)

[Patrick Garner]

We have the same issue here in suburban Atlanta but with Comcast. The
Comcast ped in my front yard has no cover... it's exposed to the elements.
There's a bright orange cable running from there to my neighbor's house,
it's been there for at least 3 years. At the least, it doesn't touch my
property. There's other spots in my neighborhood where Comcast's bright
orange coax just runs on the ground, along the road, in the gutter. Not
saying AT is the greatest but at the very least their peds(they are so
old they still say Bellsouth) have covers and they come within 3 days of
install to bury DSL lines. I don't understand why Comcast has to choose the
absolute ugliest bright orange cables to leave everywhere. If you're going
to leave it, at least use a black cable.

Yay duopoly!
-- 
Patrick Garner
Owner
Cherokee Communications LLC
404-406-9864
patrick@cherokee.network

Re: Dropping support for the .ru top level domain

[Patrick Bryant]

I propose dropping support of the .ru domains as an alternative to the
other measures discussed here, such as dropping Russian ASNs -- which
*would* have the counterproductive effect of isolating the Russian public
from western news sources. Blocking those ASNs would also be futile as a
network defense, if not implemented universally, since the bad actors in
Russia usually exploit proxies in other countries as pivot points for their
attacks.

Preventing the resolution of the .ru TLD would not impact the Russian
public's ability to resolve and access all other TLDs. As I noted, there
are countermeasures, including Russia standing up its own root servers, but
there are two challenges to countermeasure: 1) it would require modifying
evey hints file on every resolver within Russia and, 2) "other measures"
could be taken against whatever servers Russia implemented as substitutes.
Dropping support for the .ru TLD action may incentivize the Russian State
to bifurcate its national network, making it another North Korea, but that
action is already underway.

Other arguments are political, and I do not presume to set international
political policy. I only offer a technical opinion, not a political one.
The legalistic arguments of maintaining treaties is negated by the current
state of war.

On Tue, Mar 15, 2022 at 2:29 AM Fred Baker  wrote:

> My viewpoint, and the reason I recommended against it, is that it gives
> Putin something he has wanted for a while, which is a Russia in which he is
> in control of information flows. We do for him what he has wanted for
> perhaps 20 years, and come out the bad guys - “the terrible west gut us
> off!”.  I would rather have people in Russia have information flows that
> have a second viewpoint other than the Kremlin’s. I have no expectation
> that it will get through uncensored, but I would rather it was not in any
> sense “our fault” and therefore usable by Putin’s propaganda machine.
>
> Sent from my iPad
>
> On Mar 14, 2022, at 2:14 PM, Brian R  wrote:
>
> 
> I can understand governments wanting this to be an option but I would let
> them do blocking within their countries to their own people if that is
> their desire.  This is another pandoras box.  Its bad enough that some
> countries control this already to block free flow of information.
> If global DNS is no longer trusted then many actors will start maintaining
> their own broken lists (intentionally or unintentionally).
>
>- This will not stop Russia, they will just run their own state
>sponsored DNS servers.  We can imagine what else might be implemented on
>that concept...
>- Countries or users that still want access will do the same with
>custom DNS servers.
>- This will take us down another path of no return as a global
>standard that is not political or politically controlled.
>- The belief that the internet is open and free (as much as possible)
>will be broken in one more way.
>- This will also accelerate the advancement of crypto DNS like
>NameCoin (Years ago I liked the idea but I don't know how it is being
>run anymore.) or UnstoppableDomains for example.   Similar to what is
>starting to happen to central banking as countries start shutting down bank
>accounts for political reasons.
>
> I am glad to see soo many people on here and many of the organizations
> running these services state as much.
>
> Brian
>
>
> --
> *From:* NANOG  on
> behalf of Patrick Bryant 
> *Sent:* Saturday, March 12, 2022 2:47 AM
> *To:* nanog@nanog.org 
> *Subject:* Dropping support for the .ru top level domain
>
> I don't like the idea of disrupting any Internet service. But the current
> situation is unprecedented.
>
> The Achilles Heel of general public use of Internet services has always
> been the functionality of DNS.
>
> Unlike Layer 3 disruptions, dropping or disrupting support for the .ru TLD
> can be accomplished without disrupting the Russian population's ability to
> access information and services in the West.
>
> The only countermeasure would be the distribution of Russian national DNS
> zones to a multiplicity of individual DNS resolvers within Russia. Russian
> operators are in fact implementing this countermeasure, but it is a slow
> and arduous process, and it will entail many of the operational
> difficulties that existed with distributing Host files, which DNS was
> implemented to overcome.
>
> The .ru TLD could be globally disrupted by dropping the .ru zone from the
> 13 DNS root servers. This would be the most effective action, but would
> require an authoritative consensus. One level down in DNS delegation are
> the 5 authoritative servers. I will leave it to the imagination of others
> to e

Dropping support for the .ru top level domain

[Patrick Bryant]

I don't like the idea of disrupting any Internet service. But the current
situation is unprecedented.

The Achilles Heel of general public use of Internet services has always
been the functionality of DNS.

Unlike Layer 3 disruptions, dropping or disrupting support for the .ru TLD
can be accomplished without disrupting the Russian population's ability to
access information and services in the West.

The only countermeasure would be the distribution of Russian national DNS
zones to a multiplicity of individual DNS resolvers within Russia. Russian
operators are in fact implementing this countermeasure, but it is a slow
and arduous process, and it will entail many of the operational
difficulties that existed with distributing Host files, which DNS was
implemented to overcome.

The .ru TLD could be globally disrupted by dropping the .ru zone from the
13 DNS root servers. This would be the most effective action, but would
require an authoritative consensus. One level down in DNS delegation are
the 5 authoritative servers. I will leave it to the imagination of others
to envision what action that could be taken there...

ru  nameserver = a.dns.ripn.net
ru  nameserver = b.dns.ripn.net
ru  nameserver = d.dns.ripn.net
ru  nameserver = e.dns.ripn.net
ru  nameserver = f.dns.ripn.net

The impact of any action would take time (days) to propagate.

Re: New minimum speed for US broadband connections

[Patrick Clochesy]

California in particular also has more stringent rules for commercial
buildings with seismic requirements. While a nonpen mount is great, you
still have to get the service into the building somehow.

Back in 2005 when I moved to this area, I worked directly across the street
from what is now the stadium - at that time it was Great America's parkling
lot. The area still shows dead on the CA broadband map, but all we could
get was AT DSL or your typical telco circuits. This is despite being in a
very urban area in the heart of Silicon Valley, JUST up the road from the
datacenter we used at the time (Globix). We ended up having to do a
wireless P2P to the McAfee building up the road, and getting the cable from
the roof in I'm pretty sure required the contractor to x-ray the roof after
they were done which I believe was pre-stressed concrete panels.

To this day, many of those dead zones still exist. I've been to many RURAL
areas with far more consistent Internet access than Silicon Valley, and it
certainly does seem odd.

-Patrick

On Wed, Feb 16, 2022 at 7:04 PM Cory Sell via NANOG  wrote:

> Out of pure curiosity, let’s assume they COULD put an antenna on the roof…
>
> What is the service? Bandwidth, latency expectation, cost?
>
> Note that in almost every condominium or apartment complex I have heard
> of, they do NOT allow roof builds. This is why satellite TV in those areas
> require people to put an antenna on their patio, even if it’s half-blocked.
>
> On Wed, Feb 16, 2022 at 6:51 PM, Mike Lyon  wrote:
>
> If they allow antennas on the roof, we can service them :)
>
> Your house, on the other hand, we already lucked out on that one!
>
> -Mike Lyon
> Ridge Wireless
>
> On Feb 16, 2022, at 16:48, Matthew Petach  wrote:
>
> 
>
>
> On Wed, Feb 16, 2022 at 1:16 PM Josh Luthman 
> wrote:
>
>> I'll once again please ask for specific examples as I continue to see the
>> generic "it isn't in some parts of San Jose".
>>
>
>
> You want a specific example?
>
> Friend of mine asked me to help them get better Internet connectivity a
> few weeks ago.
>
> They live here:
>
> https://www.google.com/maps/place/Meridian+Woods+Condos/@37.3200394,-121.9792261,17.47z/data=!4m5!3m4!1s0x808fca909a8f5605:0x399cdd468d99300c!8m2!3d37.3190694!4d-121.9818295
>
> Just off of I-280 in the heart of San Jose.
>
> I dug and dug, and called different companies.
> The only service they can get there is the 768K DSL service they already
> have with AT
>
> Go ahead.  Try it for yourself.
>
> See what service you can order to those condos.
>
> Heart of Silicon Valley.
>
> Worse connectivity than many rural areas.   :(
>
> Matt
>
>
>
>
>

Re: Network visibility

[Patrick W. Gilmore]

> But I will capitalize Internet in all relevant uses.
> 
> This is an *engineering definition*, it matters that you name the right
> object, and I am one of the people who will, in fact, die on this hill.

You are not alone.


> The associated press can bite me.

While I respect and appreciate the AP (ap?) in general, in this particular 
instance, I am with you.

-- 
TTFN,
patrick


> On Oct 22, 2021, at 01:21, Jay R. Ashworth  wrote:
> - Original Message -
>> From: "Miles Fidelman" 
> 
>> Guys,
>> 
>> You guys were in grade school, some of us were there at the beginning
>> (well, in my case, 2 years after the beginning).  I can assure you that
>> folks made a big deal about what was and wasn't the Internet, and the
>> distinction between "an internet" and "the (capital I) Internet."
>> Opinions varied then, and opinions vary now.
>> 
>> But... by and large, as I understand the general zeitgeist:
>> 
>> - you're either on the Internet, or you're not - the key question is
>> whether you can send & receive IP packets from the public address space
>> (i.e., the classified segments are internets, but not part of THE
>> Internet).  There are also disagreements on where the Internet ends - at
>> the demarc, or at the IP stack in your machine (I argue the latter, but
>> that's debatable)
> 
> Seth Breidbart has the last word on this point, I think:
> 
> The Internet is "the largest equivalence class in the reflexive, transitive, 
> symmetric closure of the relationship 'can be reached by an IP packet from'."
> 
> The associated press has, in the last year or two, disparaged the 
> capitalization
> of the word Internet, proving they do not understand there's a difference.
> 
> If they won't capitalize "my" name, I won't capitalize theirs.
> 
> But I will capitalize Internet in all relevant uses.
> 
> This is an *engineering definition*, it matters that you name the right
> object, and I am one of the people who will, in fact, die on this hill.
> 
> The associated press can bite me.
> 
> 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

Re: Internet history

[Patrick W. Gilmore]

On Oct 21, 2021, at 2:37 PM, Michael Thomas  wrote:
> 
> [changed to a more appropriate subject]
> 
> On 10/20/21 3:52 PM, Grant Taylor via NANOG wrote:
>> On 10/20/21 3:26 PM, Michael Thomas wrote:
>>> Just as an interesting aside if you're interested in the history of 
>>> networking, When Wizards Stayed Up Late is quite elucidating.
>> 
>> +10 to Where Wizards Stay Up Late.
>> 
>> I recently re-acquired (multiple copies of) it.  (Multiple because I wanted 
>> the same edition that I couldn't locate after multiple moves.)
>> 
>> 
> One of the things about the book was that it finally confirmed for me what I 
> had heard but thought might be apocryphal which was that one of my co-workers 
> at Cisco (Charlie Klein) was the first one to receive a packet on ARPAnet. I 
> guess it sent an "l" and then immediately crashed. They fixed the problem and 
> the next time they got "login:". It also casts shade on another early well 
> known person which gives me some amount of schadenfreude.

It was “LO”, and Mr. Kline sent the packets, but you got it essentially right.

Source: https://uclaconnectionlab.org/internet-museum/

The last picture confirms Mr. Kline sent the LO and crashed the WHOLE INTERENT 
(FSVO “Internet”) just a couple seconds after it started. I wonder if he will 
ever live it down. :-) Apparently at the time it was not that big a deal. He 
did the test at 10:30 PM. He did not call and wake anyone up, everyone had to 
read about it in the notes the next day.

My understanding is that really is IMP No. 1. Someone found it in the “to be 
scrapped” pile & rescued it, then they closed off room 3420 & made it a 
micro-museum. I believe the teletype is not the original, but is a real ASR-33. 
The Sigma 7 is a prop, I believe.

Anyone can visit it for free (other than parking, which is expensive near 
UCLA!). If you are near UClA, you should stop by. To be honest, it is both 
overwhelming and underwhelming. Overwhelming because of what it was and 
represents. Underwhelming because it is a tiny classroom with a half-glass 
locked door and a plaque in the basement of the mathematics department at a 
public university that looks like it was built in the 40s. I went to UCLA for 
mathematics, and spent quite a bit of time in that hallway without even 
realizing what that room was. (It was not a museum at the time.)

-- 
TTFN,
patrick

Re: abha

[Patrick W. Gilmore]

On Oct 20, 2021, at 1:45 PM, Brett Watson  wrote:
> On Oct 20, 2021, at 10:41, Randy Bush  wrote:
>> 
>> abha died 20 years ago today
> 
> Still miss her, she was a ray of sunshine.

I can still hear her laugh, see her smile. Which makes me happy and sad at the 
same time.

We all owe her. NANOG would not be what it is today without her efforts.

-- 
TTFN,
patrick

Re: Facebook post-mortems...

[Patrick W. Gilmore]

Update about the October 4th outage

https://engineering.fb.com/2021/10/04/networking-traffic/outage/

-- 
TTFN,
patrick

> On Oct 4, 2021, at 9:25 PM, Mel Beckman  wrote:
> 
> The CF post mortem looks sensible, and a good summary of what we all saw from 
> the outside with BGP routes being withdrawn. 
> 
> Given the fragility of BGP, this could still end up being a malicious attack. 
> 
> -mel via cell
> 
>> On Oct 4, 2021, at 6:19 PM, Jay Hennigan  wrote:
>> 
>> On 10/4/21 17:58, jcur...@istaff.org wrote:
>>> Fairly abstract - Facebook Engineering - 
>>> https://m.facebook.com/nt/screen/?params=%7B%22note_id%22%3A10158791436142200%7D=%2Fnotes%2Fnote%2F&_rdr
>>>  
>>> <https://m.facebook.com/nt/screen/?params={"note_id":10158791436142200}=/notes/note/&_rdr>
>> 
>> I believe that the above link refers to a previous outage. The duration of 
>> the outage doesn't match today's, the technical explanation doesn't align 
>> very well, and many of the comments reference earlier dates.
>> 
>>> Also, Cloudflare’s take on the outage - 
>>> https://blog.cloudflare.com/october-2021-facebook-outage/ 
>>> <https://blog.cloudflare.com/october-2021-facebook-outage/>
>> 
>> This appears to indeed reference today's event.
>> 
>> -- 
>> Jay Hennigan - j...@west.net
>> Network Engineering - CCIE #7880
>> 503 897-8550 - WB6RDV

Re: facebook outage

[Patrick W. Gilmore]

On Oct 4, 2021, at 5:30 PM, Bill Woodcock  wrote:
> On Oct 4, 2021, at 11:21 PM, Bill Woodcock  wrote:
>> On Oct 4, 2021, at 11:10 PM, Bill Woodcock  wrote:
>>> 
>>> They’re starting to pick themselves back up off the floor in the last two 
>>> or three minutes.  A few answers getting out.  I imagine it’ll take a while 
>>> before things stabilize, though.
>> 
>> nd we’re back:
>> 
>> WoodyNet-2:.ssh woody$ dig www.facebook.com @9.9.9.9
> 
> So that was, what…  15:50 UTC to 21:05 UTC, more or less…  five hours and 
> fifteen minutes.
> 
> That’s a lot of hair burnt all the way to the scalp, and some third-degree 
> burns beyond that.
> 
> Maybe they’ll get one or two independent secondary authoritatives, so this 
> doesn’t happen again.  :-)

If by “independent” you mean “3rd party” (e.g. DynDNS), not sure what an 
external secondary would have done here. While their BGP was misbehaving, the 
app would not work even if you had a static DNS entry.

And while using external / 3rd party secondaries is likely a good idea for many 
companies, almost none of the largest do this. These companies view it as a 
control issue. Giving someone outside your own employees the ability to change 
a DNS name is, frankly, giving another company the ability to take you down.

Taking a sample of FB, cisco, Amazon, NF, Dell, Akamai, Google, MS, CF, only 2 
use 3rd party resolvers.
* NF uses only awsdns, so same problem, just moved to another company they do 
not control.
* Amazon uses Ultra & Dyn. (Anyone else amused amazon.com has no authorities on 
Route 53? At least not from my vantage point.)

That said, plenty of what people may call “big” companies do use 3rd parties, 
e.g. IBM, PayPal, Juniper.

You want to use a 3rd party DNS, go for it. There are lots of reasons to do it. 
But it is not a panacea, and there are reasons not to.

-- 
TTFN,
patrick

Re: FYI: NANOG and ICANN

[Patrick W. Gilmore]

NANOG’s version: 
https://www.nanog.org/stories/nanog-signs-a-memorandum-of-understanding-with-internet-society-icann/

-- 
TTFN,
patrick


> On Oct 4, 2021, at 4:42 AM, Hank Nussbacher  wrote:
> 
> https://www.icann.org/en/announcements/details/icann-signs-a-memorandum-of-understanding-with-nanog-27-9-2021-en
> 
> Regards,
> Hank

Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]

[Patrick W. Gilmore]

> Of course! Including headers to show authenticity. I was very amused by the 
> explanation of the "chicken and egg" problem. Who's creating that? The 
> networks
> who refuse to peer with non-peeringdb registered ASNs, or peeringdb who won't 
> recognize ASNs that are not peering with anyone because nobody wants to peer 
> with them because they are not registered in peeringdb because nobody wants to
> peer with them? You get the idea.

First, most networks do not require a PDB record to peer. (Silly of them, I 
know, but still true.)

Second, you do not need to have a PDB record to get a link to an IXP. Even 
membership in a free IXP is sufficient for an account in PDB, as Grizz points 
out below.

Third, if you have an agreement, even just an email, saying a network will peer 
with you once you have a record, that may well suffice. Have you asked any 
network to peer? Private peering (because you are not on an IXP) is usually 
reserved for networks with more than a modicum of traffic. If your network is 
large enough to qualify for private peering, I have trouble believing you 
cannot get another network to agree to peer so you can get a record.

I guess you are right, the _Peering_DB does not register “certain” networks. 
Those networks would be ones that do not peer. Which seems pretty obvious to me 
- it is literally in the name.

-- 
TTFN,
patrick

> On Aug 18, 2021, at 5:50 PM, Sabri Berisha  wrote:
> 
> ----- On Aug 18, 2021, at 2:21 PM, Patrick W. Gilmore patr...@ianai.net 
> <mailto:patr...@ianai.net> wrote:
> 
> Hi,
> 
>> On Aug 18, 2021, at 5:00 PM, Matthew Walster  wrote:
>>> On Wed, 18 Aug 2021, 21:37 Sabri Berisha,  wrote:
>>> - On Aug 18, 2021, at 2:46 AM, Steve Lalonde st...@enta.net wrote:
>>> 
>>> Hi,
>>> 
>>>>> We always use PeeringDB data and refuse to peer with networks not in 
>>>>> PeeingDB
>>>> 
>>>> You are aware that PeerinDB refuses to register certain networks, right? 
>>>> It is
>>>> most certainly not a single source of truth.
>>>> 
>>> Would you care to expand on this?
>> 
>> I am extremely interested in hearing about this as well.
>> 
>> Specific examples would be useful.
> 
> Of course! Including headers to show authenticity. I was very amused by the 
> explanation of the "chicken and egg" problem. Who's creating that? The 
> networks
> who refuse to peer with non-peeringdb registered ASNs, or peeringdb who won't 
> recognize ASNs that are not peering with anyone because nobody wants to peer 
> with them because they are not registered in peeringdb because nobody wants to
> peer with them? You get the idea.
> 
> Thanks,
> 
> Sabri
> AS31064
> 
> 
> Return-Path: gr...@peeringdb.com <mailto:gr...@peeringdb.com>
> Received: from mail.cluecentral.net <http://mail.cluecentral.net/> (LHLO 
> mail.cluecentral.net <http://mail.cluecentral.net/>)
> (195.16.84.32) by mail.cluecentral.net <http://mail.cluecentral.net/> with 
> LMTP; Fri, 9 Oct 2015 01:47:22
> -0700 (PDT)
> Received: from localhost (localhost [127.0.0.1])
>   by mail.cluecentral.net <http://mail.cluecentral.net/> (Postfix) with 
> ESMTP id 4CED64001EF
>   for mailto:sa...@cluecentral.net>>; Fri,  9 Oct 
> 2015 01:47:22 -0700 (PDT)
> Received: from mail.cluecentral.net <http://mail.cluecentral.net/> 
> ([127.0.0.1])
>   by localhost (mail.cluecentral.net <http://mail.cluecentral.net/> 
> [127.0.0.1]) (amavisd-new, port 10024)
>   with ESMTP id 3TLvVaNdjHGA for  <mailto:sa...@cluecentral.net>>;
>   Fri,  9 Oct 2015 01:47:21 -0700 (PDT)
> Received: from ubersmith.peeringdb.com <http://ubersmith.peeringdb.com/> 
> (ubersmith.peeringdb.com <http://ubersmith.peeringdb.com/> [107.6.74.106])
>   by mail.cluecentral.net <http://mail.cluecentral.net/> (Postfix) with 
> ESMTP id C5B164001A9
>   for mailto:sa...@cluecentral.net>>; Fri,  9 Oct 
> 2015 01:47:01 -0700 (PDT)
> Received: by ubersmith.peeringdb.com <http://ubersmith.peeringdb.com/> 
> (Postfix, from userid 48)
>   id D8AF377C1A; Fri,  9 Oct 2015 04:46:29 -0400 (EDT)
> Date: Fri, 9 Oct 2015 04:46:29 -0400
> To: Sabri Berisha mailto:sa...@cluecentral.net>>
> From: supp...@peeringdb.com <mailto:supp...@peeringdb.com>
> Reply-To: supp...@peeringdb.com <mailto:supp...@peeringdb.com>
> Subject: Re: [#9192] [PeeringDB] User (sabri) Requesting Access (New Company 
> - Cluecentral Inc)
> Message-ID: <1bac170d74e5d3702d3a28b237c87...@ubersmith.peeringdb.com 
> <mailto:1bac170d74e5d3702d3a28b237c87...@ubersmith.peeringdb.com>>
> 
> Dear

PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]

[Patrick W. Gilmore]

On Aug 18, 2021, at 5:00 PM, Matthew Walster  wrote:
> On Wed, 18 Aug 2021, 21:37 Sabri Berisha,  wrote:
> - On Aug 18, 2021, at 2:46 AM, Steve Lalonde st...@enta.net wrote:
> 
> Hi,
> 
>> > We always use PeeringDB data and refuse to peer with networks not in 
>> > PeeingDB
>> 
>> You are aware that PeerinDB refuses to register certain networks, right? It 
>> is most certainly not a single source of truth.
>> 
> Would you care to expand on this?

I am extremely interested in hearing about this as well.

Specific examples would be useful.

-- 
TTFN,
patrick

Re: AS 3356 (Level 3) -- Community 3356:666

[Patrick Schultz]

$ whois AS3356 -h rr.level3.net | grep -E 'blackhol|666'
remarks:   3356:666 - Peer route
remarks:   3356: - blackhole (discard) traffic

--
Patrick

Am 04.08.2021 um 15:28 schrieb Sriram, Kotikalapudi (Fed) via NANOG:

There is an old NANOG thread from 2005 that said AS 3356 (Level 3) were 
applying 3356:666 to indicate Peer route:
https://archive.nanog.org/mailinglist/mailarchives/old_archive/2005-12/msg00280.html
Also, see: https://onestep.net/communities/as3356/

Now network operators commonly use ASN:666 for BGP Blackholing Community.
(ASN = the operator's AS number)
See, for example, https://www.he.net/adm/blackhole.html

Does anyone know if AS 3356 has changed how it uses 3356:666?
I.e., is it known if they now use it for Blackholing Community?

Thank you.

Sriram
 

Re: FreeBSD's ping Integrates IPv6

[Patrick Cole]

Mark, 

iputils-ping on linux seems to behave the same for quite some time...

[z@tyl][~] % host ns0 
ns0.spirit.net.au has address 27.113.240.197
ns0.spirit.net.au has IPv6 address 2403:3600:8002::100

[z@tyl][~] % ping ns0  
PING ns0(2403:3600:8002::100 (2403:3600:8002::100)) 56 data bytes
64 bytes from 2403:3600:8002::100 (2403:3600:8002::100): icmp_seq=1 ttl=63 
time=0.344 ms
64 bytes from 2403:3600:8002::100 (2403:3600:8002::100): icmp_seq=2 ttl=63 
time=0.447 ms


-PC

Fri, Jul 02, 2021 at 04:00:16PM +0200, Mark Tinka wrote:


>Hi all.
> 
>I just noticed (although it appears to have come in version 13.0) that
>FreeBSD's "ping" app now defaults to IPv6, i.e., no need for ping6:
> 
>    https://www.freebsd.org/cgi/man.cgi?query=ping=8=html
> 
>Does anyone know whether other *nix systems are doing this now?
> 
>My Mac (Catalina) still requires ping6, and I don't have any recent Linux
>systems handy.
> 
>#ThisIsGood
> 
>Mark.

-- 
Patrick Cole 
Chief Architect
Spirit Technology Solutions
19-25 Raglan St, South Melbourne VIC 3205
Desk:0385541391
Mobile:  0410626630

Re: [nanog] Famous operational issues

[Patrick Schultz]

opening the link currently gives me a HTTP 500 error, very fitting :)

Am 12.06.2021 um 04:42 schrieb Dan Mahoney:
> I only just now found this thread, so I'm sorry I'm late to the party, but 
> here, I put it on Medium.
>
> https://gushi.medium.com/the-worst-day-ever-at-my-day-job-beff7f4170aa
>
>> On Mar 12, 2021, at 10:07 PM, Mark Tinka  wrote:
>>
>> Hardly famous and not service-affecting in the end, but figured I'd share an 
>> incident from our side that occurred back in 2018.
>>
>> While commissioning a new node in our Metro-E network, an IPv6 
>> point-to-point address was mis-typed. Instead of ending in /126, it ended in 
>> /12. This happened in Johannesburg.
>>
>> We actually came across this by chance while examining the IGP table of 
>> another router located in Slough, and found an entry for 2c00::/12 floating 
>> around. That definitely looked out of place, as we never carry parent blocks 
>> in our IGP.
>>
>> Running the trace from Slough led us back to this one Metro-E device in 
>> Jo'burg.
>>
>> It took everyone nearly an hour to figure out the typo, because for all the 
>> laser focus we had on the supposed link of the supposed box that was 
>> creating this problem, we all overlooked the fact that the /12 configured on 
>> the point-to-point link was
>> actually supposed to have been a /126.
>>
>> The reason this never caused a service problem was because we do not 
>> redistribute our IGP into BGP (not that anyone should). And even if we did, 
>> there are a ton of filters and BGP communities on all devices to ensure a 
>> route such as that would have
>> never made it out of our AS.
>>
>> Also, the IGP contains the most specific paths to every node in our network, 
>> so the presence of the 2c00::/12 was mostly cosmetic. It would have never 
>> been used for routing decisions.
>>
>> Mark.
>

Re: MPLS/MEF Switches and NIDs

[Patrick Cole]

Colton,

This was 6+ years ago, SAOS 6.14, so I don't know it might be better now.

We changed to Cisco ASR920 and it was a night and day difference - we now have
90ish ASR920s in production but are migrating toward the NCS540X.

Patrick

Sat, May 29, 2021 at 10:13:13AM -0500, Colton Conor wrote:


>    Patrick,
>How long ago was this, and what code were they running?
>What do you recommend for aggregation then?
>On Fri, May 28, 2021 at 9:17 PM Patrick Cole  wrote:
> 
>  We ran a medium sized mpls network using ciena 3900 and 5000 series
>  boxes on our microwave network.
>  Nothing but problems, the mpls code was just not mature enough and our
>  radio network had the boxes falling apart at the seams as storms rolled
>  through.  At that time they didn't support FRR or proper CSPF so
>  everything had to be manually engineered active standby LSPs. Not sure
>  if things have changed now. These boxes have Nortel vintage and they
>  seemed best delloyed using PBB TE as it was mature. 
>  As an NID though they are not a bad option but not in core or
>  aggregation IMHO. 
> 
>  On 29 May 2021 08:49:51 Colton Conor  wrote:
> 
>Yes, I was surprised as you that they have these routing features. I
>was also surprised they had multiple boxes that compete with
>aggregation devices like the ACX5048. The question is how good is
>Ciena's MPLS, switching, and routing stack compared to the established
>players of Juniper, Cisco, and Nokia? Ciena is no small company, so I
>think they would have the resources to make it happen.
>On Fri, May 28, 2021 at 12:32 PM  wrote:
> 
>  Wow, ciena has the means to implement SR and MPLS services?  I mean
>  they run the underlying LS IGP to signal those SIDâ**s ??  I
>  didnâ**t know that.  I may look at them in the future then.  I
>  thought Ciena just did some sort of static mpls-tp or somethingâ*¦
> 
>   
> 
>  We use Accedian as NIDâ**s with SkyLight director for PAA (SLA
>  stuff)â*¦and uplink those into our network at (yester-year, Cisco
>  ME3600â**s and ASR9000â**s), but now, ACX5048 and MX204
> 
>   
> 
>  -Aaron
> 
>   

-- 
Patrick Cole 
Chief Engineer
Spirit Technology Solutions
19-25 Raglan St, South Melbourne VIC 3205
Desk:0385541391
Mobile:  0410626630

Re: MPLS/MEF Switches and NIDs

[Patrick Cole]

We ran a medium sized mpls network using ciena 3900 and 5000 series boxes 
on our microwave network.


Nothing but problems, the mpls code was just not mature enough and our 
radio network had the boxes falling apart at the seams as storms rolled 
through.  At that time they didn't support FRR or proper CSPF so everything 
had to be manually engineered active standby LSPs. Not sure if things have 
changed now. These boxes have Nortel vintage and they seemed best delloyed 
using PBB TE as it was mature.


As an NID though they are not a bad option but not in core or aggregation IMHO.


On 29 May 2021 08:49:51 Colton Conor  wrote:
Yes, I was surprised as you that they have these routing features. I was 
also surprised they had multiple boxes that compete with aggregation 
devices like the ACX5048. The question is how good is Ciena's MPLS, 
switching, and routing stack compared to the established players of 
Juniper, Cisco, and Nokia? Ciena is no small company, so I think they would 
have the resources to make it happen.



On Fri, May 28, 2021 at 12:32 PM  wrote:
Wow, ciena has the means to implement SR and MPLS services?  I mean they 
run the underlying LS IGP to signal those SID’s ??  I didn’t know that.  I 
may look at them in the future then.  I thought Ciena just did some sort of 
static mpls-tp or something…


We use Accedian as NID’s with SkyLight director for PAA (SLA stuff)…and 
uplink those into our network at (yester-year, Cisco ME3600’s and 
ASR9000’s), but now, ACX5048 and MX204


-Aaron

Re: FCC fines for unauthorized carrier changes and consumer billing

[Patrick W. Gilmore]

On Apr 23, 2021, at 12:47 PM, Sean Donelan  wrote:
> On Fri, 23 Apr 2021, Dan Hollis wrote:
>> On Fri, 23 Apr 2021, Eric Kuhnke wrote:
>>> Did the FCC ever collect its $50 million from "Sandwich Isles
>>> Telecommunications" for blatant fraud?  At this scale I wonder how or why
>>> certain people are not in federal prison.
>> 
>> FCC is not law enforcement. The FTC can send people to prison. The FCC can 
>> only send press releases.
> 
> Neither FCC nor FTC can send people to prison. Only the Department of Justice 
> can criminally prosecute people (or corporations, i.e. WORLDCOM, ENRON, etc) 
> in the U.S. Federal system.  States and other countries vary.
> 
> FCC can deny future licenses and make things difficult for long-term 
> carriers. Most scammers declare bankruptcy or just never pay.
> 
> 
> https://www.politico.com/story/2015/11/fcc-fine-enforcement-scrutiny-216121
> FCC proposes millions in fines, collects $0
> November 23, 2015

It just got harder for the FTC to fine people: 
https://www.morningbrew.com/daily/stories/2021/04/22/supreme-court-limits-ftcs-ability-recoup-illgotten-gains

-- 
TTFN,
patrick

Re: Submitting Fake Geolocation for blocks to Data Brokers and RIRs

[Patrick W. Gilmore]

On Apr 22, 2021, at 7:58 PM, nanoguser100 via NANOG  wrote:
> 
> I see a lot of replies about the legality.  As mentioned I have legitimate 
> reasons for doing this.  I plan on serving customers in country.

Your “legitimate” reason is to avoid someone else’s restrictions on the content 
they own. You are intentionally falsifying data to keep the owner of something 
from controlling that thing the way they want to control it.

You and I have different definitions of “legitimate”.


> My questions really are:
> 
> * Is most geo data simply derived from self reporting?

No comment.


> * Do these vendors have verification mechanisms?

Yes.


> * Going to the Estonia\Germany example would a traceroute "terminating" in 
> Germany before being handed off to my network 1ms away be a tell-tale sign 
> the servers are in Germany.

Yes.

BTW: Adding artificial latency to mimic a trip back to Estonia is a bad idea, 
IMHO.


> * Is the concept of creating "pseudoPOPs" where it's not cost effective to 
> start a POP in the region a 'common practice'?

No, but it is not unheard-of.


> * Do I run the risk of being blacklisted for this practice?

Risk? Blacklisted where?

The risk of another ISP filtering your traffic for this is very low, almost 
certainly to the right of the decimal, but not mathematically zero to infinite 
decimal places. As I mentioned before, the risk of geo-loc providers ignoring 
any of your manual updates in the future is higher, but still low. Most of 
those things are automated.

-- 
TTFN,
patrick



> 
> ‐‐‐ Original Message ‐‐‐
> On Wednesday, April 21, 2021 9:00 AM, nanoguser100 via NANOG 
>  wrote:
> 
>> I wanted to get the communities' opinion on this.
>> 
>> I am an admin for a quasi-ISP providing cloud hosted desktop solutions for 
>> end users.  We have POPs all around the world, own our own ASN, and 
>> advertise /24s or /23s at each of our POPs fro our large aggregate.  As an 
>> ISP we submit our blocks to popular geolocation vendors such as Google, 
>> Maxmind, IP2, etc and put the proper geolocations in our RIR records (RADB, 
>> ARIN, etc).
>> 
>> Increasingly I have run into 'niche needs' where a client has a few users in 
>> a country we don't have a POP, say Estonia.  This is 'mainly' for 
>> localization but also in some cases for compliance (some sites REQUIRE an 
>> Estonian IP).  With that being said is it common practice to 'fake' 
>> Geolocations?  In this case the user legitimately lives in Estonia, they 
>> just happen to be using our cloud service in Germany.  I do want to operate 
>> in compliance with all the ToS as I don't want to risk our ranges getting 
>> blacklisted or the geo vendors stop accepting our data.  I would think it's 
>> pretty easy to tell given a traceroute would end in Germany even though 
>> you're claiming the IP is in Estonia.  How common of a practice is it to 
>> 'fake' the geos?  Is it an acceptable practice? 
>> 
>> 
>> Sent with ProtonMail Secure Email.
>> 
> 

Re: Submitting Fake Geolocation for blocks to Data Brokers and RIRs

[Patrick W. Gilmore]

On Apr 22, 2021, at 10:23 AM, Matthew Petach  wrote:
> On Thu, Apr 22, 2021 at 7:12 AM nanoguser100 via NANOG  
> wrote:
>> William,
>> 
>> The plan is to carve out a /24 for "Estonia" and have special servers on it. 
>>  This would be the same /24 I'd have to use if I were to put a legitimate 
>> POP there.  This also means I don't conflict with the real Germany.
>> 
>> I am just worried about violating the 'rules' of these providers and getting 
>> myself blacklisted from submitting corrections.  Afterall the traceroute 
>> will still show us hitting a router in Germany before it hits my network.  
>> Traceroutes aren't the end all be all but it's a tell-tale sign.
>> 
>> I guess this is all ISP-reported info so it's not "illegal" or a violation 
>> in any way.
>> 
>> -Nanoguser100

Love the fact you try to anonymize the question - after giving details like 
“server is in German, we want it to appear in Estonia”.

Anyway



> I think it's safe to say that before anyone could be 
> held accountable for geolocation data, there would 
> have to *first* be a requirement that the data be able 
> to be reliably updated to be *correct*.

Matt: I find it amusing you think rationality and logic have anything to do 
with government activity. You are not usually this naïve.


> As we have not yet achieved a way of ensuring that 
> legitimate holders of IP resources can reliably update 
> the geolocation data, I think you can rest assured, 
> nobody will be holding you accountable for whatever 
> the geolocation data might show for a particular block 
> of addresses.

I am not at all certain of this. At the very least, the maintainer of the 
information may hold it against you if they find out you have intentionally 
falsified the data. Remember, the people offering IP address <> Geo-location 
databases for money are not beholden to you. They are beholden to the people 
paying them money. If $CONTENT_OWNER wants to ensure only devices in Estonia 
get certain content, and you go out of your way to allow devices in German get 
the content, this could present a problem.

Will they sue you? I cannot see that happening. Will they ignore any future 
updates you give them? Would not surprise me.

BTW: I know VPN providers advertise this precise ability. However, at least the 
VPN end point is where they say it is.


> Now, if, as an industry, we had a consistent, reliable 
> way in which geolocation records could be updated 
> with a means to audit and ensure the updates are 
> being made only by the legitimate holders of the 
> number resources...*then* you might have reason 
> to be concerned.

Wait, I thought we did. At least I see it in every movie….


> But as of now, as evidenced by the number of 
> "how do I get my geolocation data updated" 
> emails sent to NANOG, which result in a flurry 
> of "meetoo" followups, no reasonable court 
> would ever give any legal credence to the 
> current data in the various geolocation 
> databases.

I find a difference between “we tried to keep the data straight, but there are 
mistakes” and “this data was intentionally misrepresented”. My guess is the law 
might as well.

As stated above, I seriously doubt anyone will someone sue you over it. Will 
you go to jail? Yeah, again, I cannot see that happening. Doesn’t mean you 
should do it.


> You can sleep soundly at night, whichever 
> road you may choose to take.

What is this “sleep” you mention?

-- 
TTFN,
patrick

Re: Zayo or HE for IP transit

[Patrick W. Gilmore]

Hurricane has probably the most peering of any large network on the  planet. 
They also carry more v6 traffic than anyone. But they have a famous problem 
with v6 - you cannot get to Cogent (174) from HE. Since you have Cogent, that 
should not be a problem. Private, smart people, customer service is excellent, 
generally good network. One minor thing to keep in mind: They do not have as 
many weird “features” as some of the other big networks. If you are looking for 
something very specific (as opposed to vanilla transit), you should check to 
see if they support it. Not saying they won’t, just saying I would check. 
Which, frankly, is good advice for any network.

I have not used Zayo in many years, so cannot comment on them.

-- 
TTFN,
patrick

> On Apr 19, 2021, at 5:30 PM, James Lumby  wrote:
> 
> What is the current experience with Zayo or HE?  I’m looking at possibly 
> adding one of them into a mix of cogent and a mix from my datacenter.  Would 
> be using BGP full routes.  Any experiences would be appreciated.
>  
> Sincerely, 
> James

Re: OOB management options @ 60 Hudson & 1 Summer

[Patrick W. Gilmore]

On Apr 16, 2021, at 1:49 PM, Warren Kumari  wrote:
> On Fri, Apr 16, 2021 at 1:08 PM Bryan Fields  wrote:
>> On 4/16/21 1:33 AM, Saku Ytti wrote:
> > https://www.markleygroup.com/cloud/network/out-of-band
> 
> Wow, this is an impressive offering.  I wish more providers would do this.
> 
> +manylots. It's always surprising to me how often companies (in all 
> industries) can be broken up into those that understand the value of goodwill 
> and those that instead nickel-and-dime.
> My local Potbelly (sandwich ship) every now and then will just say "No 
> charge, this one's on us". This only happens around once every 30-40 times I 
> go in, but they loyalty that it has created means that I go there **way** 
> more often than I otherwise would. It also means that in the few times that 
> something goes wrong/I have a bad experience, I don't really care.
> 
> The additional profit that they've made from having me as a loyal customer 
> more than covers the cost of 1 free sammich every N. 
> 
> In many ways Markley seems similar - they feel like they understand that some 
> things (like OOB) are annoying to deal with, and that the loyalty / goodwill 
> provided by being "nice" more than repays the cost of the service.

As the person who created that product for Markley, I can tell you that is 
precisely what we were thinking.

It cost us nearly nothing, made customers stickier, generated good will, and 
created a chance to talk to them about cloud offerings or similar. The only 
“catch” is you need a fiber xconn. The thinking was it was barely more than a 
copper xconn for POTS yet you get gigabit instead of dialup, or you would have 
used fiber to another ISP anyway.

Every serious colo has enough bandwidth that 2 Mbps won’t be noticed, competent 
network engineers (one hopes), and free switch ports (or can get them cheap). 
Why don’t they do this? Perhaps someone in finance feels it can be “monetized”. 
I feel the monetization lowers adoption and kills the other benefits Warren 
mentions above - which are worth a hell of a lot more than the paltry sum they 
would get from billing a few customers.

-- 
TTFN,
patrick

PS: The guest SSID at Markley has no captive portal. It was a problem for 
customers who wanted to have their equipment get on the wifi to download 
images, etc, so we took it off.

Re: Texas ERCOT power shortages (again) April 13

[Patrick W. Gilmore]

The issue was not only perfectly foreseeable, ERCOT has a ten year old document 
explaining PRECISELY how to avoid such an occurrence happening.

Did you miss the second paragraph below?

-- 
TTFN,
patrick

> On Apr 14, 2021, at 11:35 AM, Brian Johnson  wrote:
> 
> Not what I was saying. The demand for virtue-signaling green energy is not an 
> effective strategy to actually having power available.
> 
> I appreciate the nuances, but the need to imply that a profit motive was the 
> issue is not proven. This issue was NOT foreseeable except with the perfect 
> reverse 20/20 vision. It’s like saying that I shouldn’t have built the house 
> where the tornado hit.
> 
>> On Apr 14, 2021, at 10:12 AM, Patrick W. Gilmore > <mailto:patr...@ianai.net>> wrote:
>> 
>> Brian:
>> 
>> The idea that because ERCOT is a non-profit somehow means they would never 
>> do anything to save money, or management is not granted bonuses or salary 
>> increases based on savings, or have no financial incentive is ridiculous. 
>> E.g. Salaries for the top ERCOT executives increased 50% from 2012 to 2019. 
>> “Just pointing out facts.” 
>> 
>> Also, green vs. traditional has little to do with why ERCOT had problems. It 
>> is undisputed that ERCOT failed in 2011, was handed a report by the feds 
>> showing why they failed and how to fix it, yet ERCOT did not require 
>> suppliers to enact those fixes. Those actions had a direct, operational 
>> effect on the Internet. And as such, seem perfectly on-topic for NANOG.
>> 
>> Why that happened may still be on topic. For instance, you state correctly 
>> that ERCOT is a non-profit (although you and I disagree on precisely how 
>> that affects things). But the suppliers are not. Are we 100% certain the 
>> CEO’s salary jumping far far far far far faster than inflation had nothing 
>> to do with protecting the suppliers’ profits? I am not. However, that 
>> question is only tenuously operational.
>> 
>> Bringing it back to the topic on hand: How do we keep the grid up? Or plan 
>> for it not being up? Simply saying “green power is unreliable” is not an 
>> answer when many RFPs at least ask what percentage of your power is green, 
>> or flat out require at least some of your production be green. Making a 
>> blanket statement that “XXX is a non-profit” does not absolve them from poor 
>> business practices, which at least saves the non-profit money and frequently 
>> results in profits outside that entity. Etc.
>> 
>> -- 
>> TTFN,
>> patrick
>> 
>> 
>>> On Apr 14, 2021, at 10:00, Brian Johnson >> <mailto:brian.john...@netgeek.us>> wrote:
>>> 
>>> There is no profit motive for a non-profit company. It’s completely 
>>> relevant to your response.
>>> 
>>> For profit companies have similar issues with power generation and 
>>> maintenance as the way power is generated requires maintenance. No power 
>>> system is generating at 100% of capability at any single point. Your 
>>> assumptions of neglect, poor maintenance and failing to learn are 
>>> subterfuge. Traditional methods are more reliable (so far) than the newer 
>>> “green” methods.
>>> 
>>> Just pointing out facts.
>>> 
>>>> On Apr 14, 2021, at 8:26 AM, Tom Beecher >>> <mailto:beec...@beecher.cc>> wrote:
>>>> 
>>>> Brian-
>>>> 
>>>> I am aware. That's also not relevant at all to the point. 
>>>> 
>>>> On Wed, Apr 14, 2021 at 9:22 AM Brian Johnson >>> <mailto:brian.john...@netgeek.us>> wrote:
>>>> Tom,
>>>> 
>>>> You do realize that ERCOT is a non-profit organization….
>>>> 
>>>>> On Apr 14, 2021, at 8:04 AM, Tom Beecher >>>> <mailto:beec...@beecher.cc>> wrote:
>>>>> 
>>>>> > Funny how this obsession with a green grid has made the grid
>>>>> > unreliable, resulting in sales of gas-burning generators and
>>>>> > perishable fuel.  Dare I say it's not been worth it?
>>>>> 
>>>>> Yes, desire for renewable power sources is totally the reason that power 
>>>>> generators neglect proper preventative maintenance and adoption of 
>>>>> lessons learned during past problem periods. It absolutely has nothing to 
>>>>> do with profit being the most important thing ever. Right? 
>>>>> 
>>>>> On Wed, Apr 14, 2021 at 8:48 AM Mark Tinka >>>> <mailto:mark@tinka.a

Re: Texas ERCOT power shortages (again) April 13

[Patrick W. Gilmore]

Brian:

The idea that because ERCOT is a non-profit somehow means they would never do 
anything to save money, or management is not granted bonuses or salary 
increases based on savings, or have no financial incentive is ridiculous. E.g. 
Salaries for the top ERCOT executives increased 50% from 2012 to 2019. “Just 
pointing out facts.” 

Also, green vs. traditional has little to do with why ERCOT had problems. It is 
undisputed that ERCOT failed in 2011, was handed a report by the feds showing 
why they failed and how to fix it, yet ERCOT did not require suppliers to enact 
those fixes. Those actions had a direct, operational effect on the Internet. 
And as such, seem perfectly on-topic for NANOG.

Why that happened may still be on topic. For instance, you state correctly that 
ERCOT is a non-profit (although you and I disagree on precisely how that 
affects things). But the suppliers are not. Are we 100% certain the CEO’s 
salary jumping far far far far far faster than inflation had nothing to do with 
protecting the suppliers’ profits? I am not. However, that question is only 
tenuously operational.

Bringing it back to the topic on hand: How do we keep the grid up? Or plan for 
it not being up? Simply saying “green power is unreliable” is not an answer 
when many RFPs at least ask what percentage of your power is green, or flat out 
require at least some of your production be green. Making a blanket statement 
that “XXX is a non-profit” does not absolve them from poor business practices, 
which at least saves the non-profit money and frequently results in profits 
outside that entity. Etc.

-- 
TTFN,
patrick


> On Apr 14, 2021, at 10:00, Brian Johnson  wrote:
> 
> There is no profit motive for a non-profit company. It’s completely relevant 
> to your response.
> 
> For profit companies have similar issues with power generation and 
> maintenance as the way power is generated requires maintenance. No power 
> system is generating at 100% of capability at any single point. Your 
> assumptions of neglect, poor maintenance and failing to learn are subterfuge. 
> Traditional methods are more reliable (so far) than the newer “green” methods.
> 
> Just pointing out facts.
> 
>> On Apr 14, 2021, at 8:26 AM, Tom Beecher  wrote:
>> 
>> Brian-
>> 
>> I am aware. That's also not relevant at all to the point. 
>> 
>>> On Wed, Apr 14, 2021 at 9:22 AM Brian Johnson  
>>> wrote:
>>> Tom,
>>> 
>>> You do realize that ERCOT is a non-profit organization….
>>> 
>>>> On Apr 14, 2021, at 8:04 AM, Tom Beecher  wrote:
>>>> 
>>>> > Funny how this obsession with a green grid has made the grid
>>>> > unreliable, resulting in sales of gas-burning generators and
>>>> > perishable fuel.  Dare I say it's not been worth it?
>>>> 
>>>> Yes, desire for renewable power sources is totally the reason that power 
>>>> generators neglect proper preventative maintenance and adoption of lessons 
>>>> learned during past problem periods. It absolutely has nothing to do with 
>>>> profit being the most important thing ever. Right? 
>>>> 
>>>>> On Wed, Apr 14, 2021 at 8:48 AM Mark Tinka  wrote:
>>>>> 
>>>>> 
>>>>> On 4/14/21 13:35, Billy Croan wrote:
>>>>> 
>>>>> > Sounds like we all need to start keeping a few days reserve of energy 
>>>>> > on hand at home now because the utilities can't be trusted to keep 
>>>>> > their system online in 2021.
>>>>> 
>>>>> It just makes sense to plan along those lines, really. Despite popular 
>>>>> belief, power companies are preferring energy conservation from their 
>>>>> customers more than they do sales, because they just can't keep throwing 
>>>>> up new coal-fired or nuclear power stations a la the days of old (anyone 
>>>>> remember the 1973 and 1979 oil crises?)
>>>>> 
>>>>> Most people would assume that power companies want to sell more 
>>>>> electricity so they can make more money, but they dread the days when 
>>>>> the network is brought to its knees, even if the revenue will climb. So 
>>>>> between asking customers to save more on energy + being able to rely 
>>>>> less on fossil fuels for generation, one needs to consider their 
>>>>> personal energy security over the long term, fully or partially 
>>>>> independent of the traditional grid.
>>>>> 
>>>>> 
>>>>> > Funny how this obsession with a green grid has made the grid 
>>>>

Re: wow, lots of akamai

[Patrick W. Gilmore]

I am a bit worried about phrases like "If Akamai was doing these updates more 
frequently”. Akamai does not decide these things. You may as well say “if the 
fiber carriers sent the bits over several hours instead of all at once.” And 
please do not say you were just using shorthand. You have blamed the CDNs and 
Akamai by name several times in this thread.

I know first hand that Akamai has explained to large customers the possible 
problems with multi-GB updates to millions of users simultaneously. If the game 
company does not care, then I do not see what you expect the CDN to do about it.

Most CDNs do their best to deliver traffic optimally. It is in their own best 
interest. They want to avoid dropped packets even more than you do. If you do 
not like the way a CDN will deliver the traffic, talk to them. Perhaps there is 
a compromise, perhaps not. But most of them will at least kick ideas around to 
see what can be done.


And after all that, I still do not see what we are arguing about? You want the 
game companies to change their business model, but you do not want to change 
yours. Please do not say something like “but if they just ….” Unless you want 
the game companies to say “but if the ISPs just ….” Either way, stop trying to 
say someone else - the game provider, the CDN, the user, whoever - should 
change their model or spend their money to keep your business above water.

-- 
TTFN,
patrick

P.S. It is not 1995. “The Internet” is a bit more mature, and users expect a 
bit more.


> On Apr 1, 2021, at 6:27 PM, Matt Erculiani  wrote:
> 
> Patrick,
> 
> > Matt: Are you arguing the CDNs are at fault because the game companies tell 
> > everyone to download simultaneously, and
> > the ISPs sold the users connectivity to do that download?
> 
> While a gross oversimplification, yes, that's basically what I'm saying; I 
> know it may not be a popular opinion, but I stand by it. There aren't any 
> villains here though, just lots of good suggestions in this thread to make 
> the internet work better for everyone, without spending large swaths of money 
> to cover the demand of an infrequent, large, update for a single game.
> 
> CNDs do, however, have a responsibility to be good netizens and get this data 
> out in a manner that doesn't cause disruption. They know the technical 
> challenges of distributing that much data to the masses, the game company 
> does not, that's why they outsourced it to a CDN. If the CDN knows what the 
> gaming company is asking for is pushing the limits of our current 
> infrastructure, they have a responsibility to relay those limitations that 
> are outside of their control to their customer, as any responsible vendor 
> should. Instead, there may be an element of "oh yeah sure, we can do that" or 
> "the customer is always right" going on here and modern limitations are being 
> disregarded.
> 
> The idea behind the internet is not that every user can always have their 
> entire capacity available for a single destination regardless of what 
> everyone else is doing (and especially if they're all going to the same place 
> too), the user has purchased that capacity into their provider's network as a 
> whole, gaining access to all of their connections to all of the various 
> endpoints on the internet at a backbone and peering capacity that is 
> economically viable given normal peak demand with some cushion built-in for 
> redundancy. If that's the desire to have full capacity available to Akamai 
> available at all times, then everyone needs dedicated P2P circuits direct to 
> Akamai, but that's not practical.
> 
> If you own an ISP and you're not oversubscribing, you're not making money, 
> period. To use your analogy, if you've ever been to a gym in January, you've 
> seen a similar phenomenon first-hand. There aren't enough machines for 
> everyone, and the gym isn't going to add them because this is a once-a-year 
> thing and it goes away after a few weeks when many people get tired of 
> fulfilling their new year's resolutions. Why should the gym limit its sales 
> to exactly the capacity it has available (or add a lot more machines), when 
> it knows that for the overwhelming majority of the year, there will always be 
> dozens of empty machines across the floor?
> 
> If Akamai was doing these updates more frequently (weekly for example) then 
> sure, it is on the ISP to augment, because this has become the "new normal". 
> But these updates for a single game that happen once per quarter are hardly 
> able to be considered normal. Sure, some day 50GB updates will be the norm, 
> but that's not today, and when it is, somebody else will be pushing out 250GB 
> updates quarterly. This problem isn't going away soon, and it can't be fixed 
> permanently by just 

Re: wow, lots of akamai

[Patrick W. Gilmore]

Just so I am clear, you are saying “I would rather have it come over my 
undersea cables than from inside the datacenter”?

And you are assuming TCP transport.

-- 
TTFN,
patrick

> On Apr 1, 2021, at 6:23 PM, Tony Wicks  wrote:
> 
> This is not actually (as in yes it does matter) the case, if a file comes 
> from a CDN it is often a close and low latency source that will run up to 
> very high speeds. For example in our case we connect to local peering 
> exchanges (or PNI’s/local caches) at 100G or Nx10G with latency to the end 
> user in the 1-30ms range resulting in very large peaks of local backhaul 
> traffic. If a file is delivers from source or from remote CDN’s/exchanges 
> these are located in other countries with between 25ms (New Zealand to 
> Australia) and 130-200ms (New Zealand to LA/SJC or Singapore) latency, this 
> results in a much slower and normally barely noticeable traffic blip. Yes as 
> an ISP we need to carry the traffic in both cases but the first case can 
> result in a 20-30% local backhaul increase for a couple of hours and in the 
> second case its just BAU traffic for a day or two. Local CDN is obviously the 
> better option for cost and the consumer, but you certainly do notice the 
> traffic in local backhaul.
>  
> From: NANOG  <mailto:nanog-bounces+tony=wicks.co...@nanog.org>> On Behalf Of Tom Beecher
> Sent: Friday, 2 April 2021 10:05 am
> To: Matt Erculiani mailto:merculi...@gmail.com>>
> Cc: North American Operators' Group mailto:nanog@nanog.org>>
> Subject: Re: wow, lots of akamai
>  
>  
> If thousands of users are downloading 50G files at the same time, it really 
> doesn't matter if they are pulling from a CDN or the origin directly. The 
> volume of traffic still has to be handled. Yes, it's a burden on the ISP, but 
> it's a burden created by the usage created by their subscribers. 

Re: wow, lots of akamai

[Patrick W. Gilmore]

I am sorry, maybe I misunderstand.

Matt: Are you arguing the CDNs are at fault because the game companies tell 
everyone to download simultaneously, and the ISPs sold the users connectivity 
to do that download?

If so, are you really arguing “I sold my users XXX Mbps, but if they try to use 
it, I want *YOU* to tell them no”? Because that is what it sounds like to me.

Imagine a gym sold 10,000 memberships with 10 machines because they figured 
everyone would sit on their ass. They would be right most of the time - and 
rake in that sweet, sweet monthly cash for zero effort after the initial sale. 
But if Oprah or Cher or Biden or some other person famous enough to go by one 
name tweets “get your ass to the gym!!", does the gym really think getting mad 
at Oprah is the solution? Or do they expect Oprah to pay for the extra machines 
they have to buy now?

Selling a service you know will not work if everyone uses it simultaneously can 
be profitable, but there is risk. Do not blame third parties when you lose that 
bet.

-- 
TTFN,
patrick

> On Apr 1, 2021, at 5:04 PM, Tom Beecher  wrote:
> 
> No disrespect taken, or intended back in your direction, but again, I 
> disagree. 
> 
> If thousands of users are downloading 50G files at the same time, it really 
> doesn't matter if they are pulling from a CDN or the origin directly. The 
> volume of traffic still has to be handled. Yes, it's a burden on the ISP, but 
> it's a burden created by the usage created by their subscribers. 
> 
> 
> On Thu, Apr 1, 2021 at 4:57 PM Matt Erculiani  <mailto:merculi...@gmail.com>> wrote:
> Tom,
> 
> All due respect, but there is a massive difference between one user 
> downloading 50G and thousands of users each downloading 50G when they all go 
> to play their videogame of choice at around the same time.
> 
> -Matt
> 
> 
> 
> On Thu, Apr 1, 2021 at 2:46 PM Tom Beecher  wrote:
> A user sends a few megabytes of request and receives 50 gigs of reply. They 
> aren't DDoSing the network, but they're amplifying a single 50 gig copy they 
> receive from the mothership and turning it into likely tens of terabytes of 
> traffic.
> Yes, that's a CDN's job, but that volume of legitimate traffic and the very 
> tiny window with which it is transmitted is likely to be a burden for even 
> the largest residential ISPs.
> 
> I'm sitting at home, and I could send a 50k request for a 50G file right now 
> from a source not fronted by a CDN. What do? My ISP is still has to deliver 
> it to me. The fact that the 50G file does or does not come from a CDN is 
> irrelevant. The CDN just happens to be a point source that a lot of users 
> happen to connect to. 
> 
> CDNs want to have the best performance to users because that's what brings 
> them business. A poorly performing CDN will lose customers to a better 
> performing one. The trend for years has been instead of ISPs investing in 
> infrastructure to effectively handle the traffic that their users request, 
> they turf that to CDNs. In many cases, a CDN will put a cache box in or 
> extend a circuit at a loss to them, because they know if the performance 
> metrics get bad, business will be taken elsewhere, even if the CAUSE of the 
> poor performance is actually at the edge of, or inside , the ISPs network. 
> 
> ISPs in the US can get away with this because their users are captive and 
> rarely have an alternative choice of provider.  
> 
> 
> On Thu, Apr 1, 2021 at 4:33 PM Matt Erculiani  <mailto:merculi...@gmail.com>> wrote:
> Patrick,
> 
> > First, to be blunt, if you really think Akamai nodes are “sitting idle for 
> > weeks” before CoD comes out with a new game,
> > you are clearly confused.
> 
> "Idle" in the sense that when you look at a graph of traffic before and after 
> a large push such as this makes the rest of the week's traffic look like a 
> horizontal line at the bottom, admittedly poor word choice, yes, but far from 
> "confused" as to what CDNs do under relatively normal circumstances. 
> Otherwise very valid points you've raised.
> 
> Tom,
> 
> > Akamai, and other CDNs, do not **generate** traffic ; they serve the 
> > requests generated by users.  
> 
> A user sends a few megabytes of request and receives 50 gigs of reply. They 
> aren't DDoSing the network, but they're amplifying a single 50 gig copy they 
> receive from the mothership and turning it into likely tens of terabytes of 
> traffic.
> Yes, that's a CDN's job, but that volume of legitimate traffic and the very 
> tiny window with which it is transmitted is likely to be a burden for even 
> the largest residential ISPs.
> 
> -Matt
> 
> On Thu, Apr 1, 2021 at 2:09 PM Patrick W. Gilmore  <mailto:patr...@i

Re: wow, lots of akamai

[Patrick W. Gilmore]

Matt:

I am going to disagree with your characterization of how Akamai - and many 
other CDNs - manage things. First, to be blunt, if you really think Akamai 
nodes are “sitting idle for weeks” before CoD comes out with a new game, you 
are clearly confused.

More importantly, I know for a fact Akamai has spent ungodly amounts of money & 
resources putting content precisely where the ISPs ask them to put it, deliver 
it over the pipes the ISPs ask them to deliver it, at precisely the capacity 
the ISPs tell them.

On the other hand, I agree with your characterization of residential broadband. 
It is ridiculous to expect a neighborhood with 1,000 homes each with 1 Gbps 
links to have a terabit of uplink capacity. But it also should have a lot more 
than 10 Gbps, IMHO. Unfortunately, most neighborhoods I have seen are closer to 
the latter than the former.

Finally, this could quickly devolve into finger pointing. You say the CDNs bear 
some responsibility? They may well respond that the large broadband providers 
ask for cash to interconnect - but still require the CDNs to do all the work. 
The CDNs did not create the content, or tell the users which content to pull. 
When I pay $NATIONAL_PROVIDER, I expect them to provide me with access to the 
Internet. Not just to the content that pays that provider.

Personally, I have zero problems with the ISPs saying “give me a cache to put 
here with this sized uplink” or “please deliver to these users over this xconn 
/ IX / whatever”. I have a huge problem with the ISPs blaming the ISPs for 
delivering what the ISP’s users request.

Of course, this could all be solved if there were more competition in broadband 
in the US (and many other countries). But that is a totally different 10,000 
post thread (that we have had many dozens of times).

-- 
TTFN,
patrick

> On Apr 1, 2021, at 3:53 PM, Matt Erculiani  wrote:
> 
> Niels,
> 
> I think to clarify Jean's point, when you buy a 300mbps circuit, you're 
> paying for 300mbps of internet access. 
> 
> That does not mean that a network should (and in this case small-medium ones 
> simply can't) build all of their capacity to service a large number of 
> customer circuits at line rate at the same time for an extended period, 
> ESPECIALLY to the exact same endpoint. It's just not economically reasonable 
> to expect that. Remember we're talking about residential service here, not 
> enterprise circuits.
> 
> Therefore, how do you prevent this spike of [insert large number here] 
> gigabits traversing the network at the same time from causing issues? Build 
> more network? That sounds easy, but there are plenty of legitimate reasons 
> why ISPs can't or don't want to do that, particularly for an event that only 
> occurs once per quarter or so.
> 
> Does Akamai bear some burden here to make these rollouts less troublesome for 
> the ISPs they traverse through the last mile(s)? IMO yes, yes they do. When 
> you're doing something new and unprecedented, as Akamai frequently brags 
> about on Twitter, like having rapid, bursty growth of traffic, you need to 
> consider that just because you can generate it, doesn't mean it can be 
> delivered.  They've gotta be more sophisticated than a bunch of servers with 
> SSD arrays, ramdisks, and 100 gig interfaces, so there's no excuse for them 
> here to just blindly fill every link they have after sitting idle for 
> weeks/months at a time and expect everything to come out alright and nobody 
> to complain about it.
> 
> On Thu, Apr 1, 2021 at 1:21 PM Niels Bakker  <mailto:na...@bakker.net>> wrote:
> * nanog@nanog.org <mailto:nanog@nanog.org> (Jean St-Laurent via NANOG) [Thu 
> 01 Apr 2021, 21:03 CEST]:
> >An artificial roll out penalty somehow? Probably not at the ISP 
> >level, but more at the game level. Well, ISP could also have some 
> >mechanisms to reduce the impact or even Akamai could force a 
> >progressive roll out.
> 
> It's an online game. You can't play the game with outdated assets. 
> You'd not see walls where other players would, for example.
> 
> What you're suggesting is the ability of ISPs to market Internet access 
> at a certain speed but not have to deliver it based on conditions they 
> create.
> 
> 
> -- Niels.
> 
> 
> -- 
> Matt Erculiani
> ERCUL-ARIN

Re: Famous operational issues

[Patrick W. Gilmore]

On Feb 22, 2021, at 7:02 AM, t...@pelican.org wrote:
> On Thursday, 18 February, 2021 22:37, "Warren Kumari"  
> said:
> 
>> 4: Not too long after I started doing networking (and for the same small
>> ISP in Yonkers), I'm flying off to install a new customer. I (of course)
>> think that I'm hot stuff because I'm going to do the install, configure the
>> router, whee, look at me! Anyway, I don't want to check a bag, and so I
>> stuff the Cisco 2501 in a carryon bag, along with tools, etc (this was all
>> pre-9/11!). I'm going through security and the TSA[0] person opens my bag
>> and pulls the router out. "What's this?!" he asks. I politely tell him that
>> it's a router. He says it's not. I'm still thinking that I'm the new
>> hotness, and so I tell him in a somewhat condescending way that it is, and
>> I know what I'm talking about. He tells me that it's not a router, and is
>> starting to get annoyed. I explain using my "talking to a 5 year old" voice
>> that it most certainly is a router. He tells me that lying to airport
>> security is a federal offense, and starts looming at me. I adjust my
>> attitude and start explaining that it's like a computer and makes the
>> Internet work. He gruffly hands me back the router, I put it in my bag and
>> scurry away. As I do so, I hear him telling his colleague that it wasn't a
>> router, and that he certainly knows what a router is, because he does
>> woodwork...
> 
> Here in the UK we avoid that issue by pronouncing the packet-shifter as 
> "rooter", and only the wood-working tool as "rowter" :)

So wrong.

A “root” server is part of the DNS. A “route” server is part of BGP.


> Of course, it raises a different set of problems when talking to the 
> Australians…

Everything is weird down down. But I still like them. :-)

-- 
TTFN,
patrick

Re: Famous operational issues

[Patrick W. Gilmore]

On Feb 18, 2021, at 6:10 PM, Karl Auer  wrote:
> 
> I think it was Macchiavelli who said that one should not ascribe to
> malice anything adequately explained by incompetence…

https://en.wikipedia.org/wiki/Hanlon%27s_razor
Never attribute to malice that which is adequately explained by 
stupidity.

I personally prefer this version from Robert A. Heinlein:
Never underestimate the power of human stupidity.

And to put it on topic, cover your EPOs

In 1994, there was a major earthquake near the city of Los Angeles. City hall 
had to be evacuated and it would take over a year to reinforce the building to 
make it habitable again. My company moved all the systems in the basement of 
city hall to a new datacenter a mile or so away. After the install, we spent 
more than a week coaxing their ancient (even for 1994) machines back online, 
such as a Prime Computer and an AS400 with tons of DASD. Well, tons of 
cabinets, certainly less storage than my watch has now.

I was in the DC going over something with the lady in charge when someone 
walked in to ask her something. She said “just a second”. That person took one 
step to the side of the door and leaned against the wall - right on an EPO 
which had no cover.

Have you ever heard an entire row of DASD spin down instantly? Or taken 40 
minutes to IPL an AS400? In the middle of the business day? For the second most 
populous city in the country?

Me: Maybe you should get a cover for that?
Her: Good idea.

Couple weeks later, in the same DC, going over final checklist. A fedex guy 
walks in. (To this day, no idea how he got in a supposedly locked DC.) She says 
“just a second”, and I get a very strong deja vu feeling. He takes one step to 
the side and leans against the wall.

Me: Did you order that EPO cover?
Her: Nope.

-- 
TTFN,
patrick

Re: Viable Third Option?

[Patrick W. Gilmore]

Second vote for NTT.

Also, second vote for GTT.

-- 
TTFN,
patrick


> On Feb 17, 2021, at 14:07, David Hubbard  
> wrote:
> 
> 
> I’ve been pretty happy with NTT but their POPs can be limited; I’ve had to 
> pick up waves to them, which sometimes still comes out ahead.  I’m slowly 
> dropping Cogent due to the v6 issues.  I haven’t been able to try HE because 
> they and a frequent colo provider I use (Switch) don’t seem to get along.
>  
> From: NANOG  on behalf 
> of Mike Hammett 
> Date: Wednesday, February 17, 2021 at 11:52 AM
> To: NANOG list 
> Subject: Viable Third Option?
>  
> This is from the perspective of an eyeball network. I understand that content 
> networks would have different objectives and reasons. For instance, I have 
> little to no reason as an eyeball network to exchange traffic with any other 
> eyeball network (aside from P2P games). For a content network, getting into 
> the eyeball networks is their objective.
>  
> My crystal ball tells me this thread will spiral out of control because 
> people won't be able to keep it on topic, but it is a question that I hear 
> VERY often. I also expect a lot of purely bad or outdated information to get 
> thrown out.
>  
> Please try to keep it on topic and not being pedantic over relatively 
> unimportant details.
>  
> There are two major low-cost providers, Cogent and HE.
>  
> Cogent
> Refuses to peer IPv6 with HE
> Refuses to peer IPv6 with Google
> Aggressive sales tactics
> Hurricane
> Doesn't have Cogent IPv6 because of Cogent's refusal
> Lack of communities for anything other than blackholes
>  
> I know there are a variety of other providers such as Fusion Network that 
> operate at similar price points, but are available in way fewer locations.
>  
> What else is out there? Anyone else that isn't 5x, 10x the cost?
>  
> Cogent and HE get looked down upon (and sometimes deservedly so), but when I 
> talk to someone trying to sell me a port in 350 Cermak for 8x the cost of 
> Cogent and HE, you better have a very good argument for why you're worth 
> it...  and they never do. "We're not Cogent." "and?" Many times I'm quoted 
> transit that costs more than Cogent + IX + HE and they don't really have a 
> good argument for it.
>  
> As an eyeball, I join an IX and there goes 50% - 85% of my traffic and almost 
> all of my traffic that anyone is going to notice or complain about if there 
> are issues (video streaming).
>  
> I do understand that enterprise eyeballs may have different requirements.
>  
> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions
> 
> Midwest Internet Exchange
> 
> The Brothers WISP

Re: Half Fibre Pair

[Patrick W. Gilmore]

Back in the day, there were these things called half-circuits or half-cables.

Telephone companies in different countries would “share” a cable under the 
ocean, where the company in each country would own “half” the cable - i.e. from 
their shore to the middle of the ocean.

I have no idea what the context here is, but ….

-- 
TTFN,
patrick

> On Jan 26, 2021, at 5:02 PM, Ben Cannon  wrote:
> 
> I’d internet that to be a really weird way to describe a single strand as 
> well, but I could see a confused person asserting it’s 44 out of 88 
> wavelengths? I’ve never heard that.
> 
> Ms. Lady Benjamin PD Cannon, ASCE
> 6x7 Networks & 6x7 Telecom, LLC 
> CEO 
> b...@6by7.net <mailto:b...@6by7.net>
> "The only fully end-to-end encrypted global telecommunications company in the 
> world.”
> 
> FCC License KJ6FJJ
> 
> Sent from my iPhone via RFC1149.
> 
>> On Jan 26, 2021, at 12:51 PM, Rod Beck  
>> wrote:
>> 
>> 
>> Can someone explain to me what is a half fibre pair? I took it literally to 
>> mean a single fibre strand but someone insisted it was a large quantity of 
>> spectrum. Please illuminate. On or off list as you please. 
>> 
>> Regards, 
>> 
>> Roderick. 
>> 
>> Roderick Beck
>> VP of Business Development
>> United Cable Company
>> www.unitedcablecompany.com <http://www.unitedcablecompany.com/>
>> New York City & Budapest
>> rod.b...@unitedcablecompany.com
>> Budapest: 36-70-605-5144
>> NJ: 908-452-8183 
>> 
>> 

Re: A letter from the CEO

[Patrick W. Gilmore]

I am impressed that you stepped up, admitted the mistake, and apologized. Thank 
you for taking responsibility.

Anyone reading this who can say they never made a mistake can continue to 
criticize you. As I am about as far from that standard as one can be, I will 
consider this penance enough for your first mistake.

Fair warning: If you email nanog-l multiple times “by mistake”, that will not 
be so easily overlooked. Whether in error or not, multiple “mistakes” become a 
problem. Remember Grey’s law, "sufficiently advanced incompetence is 
indistinguishable from malice” (or the similar Heinlein’s law, or Hanlon’s 
razor, etc.). Perhaps you should spend some extra time verifying your list 
hygiene?

-- 
TTFN,
patrick

> On Nov 20, 2020, at 6:27 PM, Lady Benjamin PD Cannon  wrote:
> 
> Hi all, we never intended to spam the list, that was a total screw-up on our 
> part, one I take full responsibility for.   A list of exclusions got 
> included.   Please accept my sincere apologies.
> 
> Our key differentiator is that we encrypt our backbone links. All of ‘em. So 
> we say we’re another layer to get through in a security policy.  Idea being 
> your data are marginally safer with us than being blasted in the clear.
> 
> Again, sorry for including the list in our list like total nimrods.
> 
> —L.B.
> 
> Lady Benjamin PD Cannon, ASCE
> 6x7 Networks & 6x7 Telecom, LLC 
> CEO 
> b...@6by7.net <mailto:b...@6by7.net>
> "The only fully end-to-end encrypted global telecommunications company in the 
> world.”
> FCC License KJ6FJJ
> 
> 
> 
>> On Nov 20, 2020, at 3:20 PM, Mel Beckman > <mailto:m...@beckman.org>> wrote:
>> 
>> I’m sure the implication that “safe, secure” refers to less susceptibility 
>> to eavesdropping. But of course fiber can still be tapped trivially with 
>> angle-of-incidence intercept taps.
>> 
>>  -mel 
>> 
>>> On Nov 20, 2020, at 3:09 PM, Aaron C. de Bruyn via NANOG >> <mailto:nanog@nanog.org>> wrote:
>>> 
>>> 
>>> > high speed, safe, secure global fiber connectivity
>>> 
>>> More importantly, can someone tell me what 'safe global fiber connectivity' 
>>> is?  As opposed to 'unsafe global fiber connectivity'?
>>> 
>>> Do these guys have the market cornered on not string fiber optic cable at 
>>> throat-level across roads or something?
>>> 
>>> Freaking marketing droids.
>>> 
>>> -A
>>> 
>>> On Fri, Nov 20, 2020 at 2:25 PM Josh Luthman >> <mailto:j...@imaginenetworksllc.com>> wrote:
>>> Got this message to me directly as well as through the list.
>>> 
>>> @6x7 this list is *NOT* to be scrapped for email addresses for your 
>>> marketing purposes.  This is complete garbage.  I'll be sending a message 
>>> directly to k...@6by7.net <mailto:k...@6by7.net> as well.
>>> 
>>> Josh Luthman
>>> 24/7 Help Desk: 937-552-2340
>>> Direct: 937-552-2343
>>> 1100 Wayne St
>>> Suite 1337
>>> Troy, OH 45373
>>> 
>>> 
>>> On Fri, Nov 20, 2020 at 5:19 PM 6x7 Networks - Lady Benjamin, CEO 
>>> mailto:b...@6by7.net>> wrote:
>>>  
>>> A letter from the CEO of 6x7:
>>> 
>>> 6x7 Networks and Communications Authority of Kenya announce type approval 
>>> to import 8tbps/second internet routers.
>>> 
>>> Hi, Lady Benjamin from 6x7 here, and I'm proud to share with you an update 
>>> on me and the company.  
>>> 
>>> Through our adjunct division, 6x7 just received type approval from the 
>>> Kenyan government to import core routers capable of over 8tbps (8 terrabits 
>>> per second).  This will enable us to enter the Kenyan IP transit and 
>>> transport markets, and service both datacenter and soon office buildings 
>>> and eventually residences with high speed, safe, secure global fiber 
>>> connectivity.   The market in Kenya is severely impacted now due to limited 
>>> fiber availability, and 6x7 will leverage it's undersea connections to 
>>> bring more wholesale bandwidth into the area, creating the economy by which 
>>> we expect to grow.  
>>> 
>>> Thanks for reading, I'll be doing a regular set of these newsletters, and 
>>> if you like them or want to reach out, please contact us at k...@6by7.net 
>>> <mailto:k...@6by7.net>!
>>> 
>>> -LB
>>> Ms. Lady Benjamin Cannon, ASCE.
>>> Find Out More
>>>  
>>> <https://6x7networks.us19.list-manage.com/track/click?u=6fbc79e84e5db9ab

Re: cheap MPLS router recommendations

[Patrick Cole]

I can second that.  Mikrotik MPLS implementation is not good and lacking key 
features (speaking from personal experience also), and has not show any signs 
of improvement in quite some time.

One unit to take a look at for a cheap 10G solution is this:

https://www.zte.com.cn/global/products/bearer/Ethernet-Switch/5960-EN

Many many years ago this was mentioned by some NANOG members (Baldur?) and I 
recall one had said they were using it with some success.

-PC

Tue, Oct 27, 2020 at 06:12:10AM +, Philip Loenneker wrote:


>While I like MikroTik, I don’t recommend anyone uses it for MPLS.
> 
>There are problems with the way they handle labels that causes random
>connectivity issues, and can crash MPLS devices from other vendors. That’s
>from experience.
> 
>As an example, check out this post which was started back in 2013 and is
>still an issue in 2020:
> 
>https://forum.mikrotik.com/viewtopic.php?t=73820
> 
> 
> 
>Regards,
> 
>Philip
> 
> 
> 
>From: NANOG  On
>Behalf Of Tony Wicks
>Sent: Thursday, 22 October 2020 8:19 AM
>To: adamv0...@netconsultings.com
>Cc: 'NANOG' 
>Subject: RE: cheap MPLS router recommendations
> 
> 
> 
>Right, well in that price/performance range you either “roll your own” or
>this is your best option IMHO -
>https://mikrotik.com/product/CCR1072-1G-8Splus  and I’d pick the Mikrotik
>every time.
> 
> 
> 
> 
> 
> 
> 
>From: NANOG  On Behalf Of
>adamv0...@netconsultings.com
>Sent: Thursday, 22 October 2020 9:28 am
>To: 'Colton Conor' ; t...@pelican.org
>Cc: 'NANOG' 
>Subject: RE: cheap MPLS router recommendations
> 
> 
> 
>Just to clarify what cheap means, ideally  -$2000 to $4000 new
> 
>-new is preferred as buying used kit on second hand market one is at the
>mercy of the price fluctuations and availability.
> 
> 
> 
>And the likes of the M2400 looks good 4x10G plus some 1G, unfortunately
>there are no details on the webpage (and the datasheet can’t be
>downloaded… )
> 
> 
> 
>Are there more folks out there bundling open NOS and white-box HW along
>with the support for the whole thing?
> 
> 
> 
> 
> 
>adam

-- 
Patrick Cole 
Chief Engineer
Spirit Technology Solutions
19-25 Raglan St, South Melbourne VIC 3205
Desk:0385541391
Mobile:  0410626630

Re: Apple moved from CDN, and ARIN whois

[Patrick W. Gilmore]

Not everything is moved.

patrick@TiggerBook-C-32 ~ % dig www.apple.com
[…]
;; ANSWER SECTION:
www.apple.com.  219 IN  CNAME   www.apple.com.edgekey.net.
www.apple.com.edgekey.net. 12102 IN CNAME   
www.apple.com.edgekey.net.globalredir.akadns.net.
www.apple.com.edgekey.net.globalredir.akadns.net. 849 IN CNAME 
e6858.dsce9.akamaiedge.net.

Obviously different people will get different answers. But the point is, Apple 
is not completely off 3rd party CDNs. Or maybe they are back on 3rd party CDNs?

-- 
TTFN,
patrick

> On Sep 24, 2020, at 11:39 AM, Mike Hammett  wrote:
> 
> Breaking from current CDN infrastructure without reasonable accessibility to 
> the new CDN is a problem.
> 
> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions <http://www.ics-il.com/>
>  <https://www.facebook.com/ICSIL> 
> <https://plus.google.com/+IntelligentComputingSolutionsDeKalb> 
> <https://www.linkedin.com/company/intelligent-computing-solutions> 
> <https://twitter.com/ICSIL>
> Midwest Internet Exchange <http://www.midwest-ix.com/>
>  <https://www.facebook.com/mdwestix> 
> <https://www.linkedin.com/company/midwest-internet-exchange> 
> <https://twitter.com/mdwestix>
> The Brothers WISP <http://www.thebrotherswisp.com/>
>  <https://www.facebook.com/thebrotherswisp> 
> <https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg>
> From: "Denys Fedoryshchenko"  <mailto:nuclear...@nuclearcat.com>>
> To: nanog@nanog.org <mailto:nanog@nanog.org>
> Sent: Thursday, September 24, 2020 9:27:07 AM
> Subject: Apple moved from CDN, and ARIN whois
> 
> Hi,
> 
> Interesting, it seems AS6185 moved traffic from all CDN to their own 
> content network.
> I noticed big spikes in traffic and complaints about slowness, figured 
> out, Apple content (especially updates) are not coming from a numerous 
> co-hosted CDN, but became "live",
> congesting upstreams.
> So much efforts on collocating endless CDN in premises to keep things 
> closer to users and handle traffic surges, and yet again, some companies 
> keep inventing their own.
> 
> P.S. I dont know if it is bug, but whois at ARIN return "No match found 
> for n + 17.0.0.0/8" for 17.0.0.0/8,
> but works fine for single ip from this range, like 17.0.0.0, and returns 
> info about 17.0.0.0/8

Re: AANP Akamai

[Patrick W. Gilmore]

netsupp...@akamai.com

-- 
TTFN,
patrick

> On Sep 2, 2020, at 2:40 PM, ahmed.dala...@hrins.net wrote:
> 
> Hello NANOG, 
> 
> Could somebody from Akamai AANP’s network team contact me off-list? I’ve 
> tried the peering and NOC and got no replies in months. 
> 
> Thanks
> Ahmed

Re: BGP route hijack by AS10990

[Patrick Schultz]

I'd like to direct you to Job's writeup on this :) 
https://mailman.nanog.org/pipermail/nanog/2017-August/191897.html
While these "optimizers" CAN be beneficial to the individual operator, they're 
apparently used incorrectly in some instances.
Telia should've filtered, that's for sure. But the leak shouldn't have occured 
in the first place.

Am 30.07.2020 um 20:09 schrieb Florian Brandstetter:
> Never read something that silly, bgp optimizers are perfectly fine
> and every network operator is well within the right to run optimizers,
> you should much more ask Telia as to why they accepted the prefixes,
> and EVEN MORE ask the operator of 7219 for what specific reason they
> are blowing out their full table to 1299. Anyone with a sane mind has
> export filters where a specific community or tag serves as some kind
> of "do advertise" sign, as opposed to announcing anything BUT external.
> 
> May I know the specific reason for such poor attempt of shifting
> responsibility for this incident to bgp optimizers instead of those
> who clearly don't have a single clue about proper filtering policies?
> 
> -- 
> Greetings,
> 
> Florian Brandstetter
> Chief Executive Officer
> SquareFlow Corporation
> www.squareflow.net
> 
> Confidential: Please be advised that the information contained in this
> email message, including all attached documents or files, is privileged
> and confidential and is intended only for the use of the individual or
> individuals addressed. Any other use, dissemination, distribution or
> copying of this communication is strictly prohibited.
> 
> On 2020-07-30 19:09, Patrick Schultz wrote:
>> so, bgp optimizers... again?
>>
>> -- 
>> Patrick
>> Am 30.07.2020 um 18:58 schrieb Töma Gavrichenkov:
>>
>>> Peace,
>>>
>>> On Thu, Jul 30, 2020, 5:48 AM Clinton Work 
>>> wrote:
>>>
>>>> We saw a bunch of our IP blocks hijacked by AS10990 from 19:15 MDT
>>>> until 20:23 MDT.   Anybody else have problems with that.
>>>
>>> Here's what we discovered about the incident.  Hope that brings some
>>> clarity.
>>>
>>> https://radar.qrator.net/blog/as10990-routing-optimization-tale
>>>
>>> -- 
>>> Töma
>>>
>>>>

Re: BGP route hijack by AS10990

[Patrick Schultz]

so, bgp optimizers... again?

-- 
Patrick

Am 30.07.2020 um 18:58 schrieb Töma Gavrichenkov:
> Peace,
>
> On Thu, Jul 30, 2020, 5:48 AM Clinton Work  <mailto:clin...@scripty.com>> wrote:
>
> We saw a bunch of our IP blocks hijacked by AS10990 from 19:15 MDT until 
> 20:23 MDT.   Anybody else have problems with that.
>
>
> Here's what we discovered about the incident.  Hope that brings some clarity.
>
> https://radar.qrator.net/blog/as10990-routing-optimization-tale 
> <https://radar.qrator.net/blog/as10990-routing-optimization-tale>
>
> --
> Töma
>

Re: Don Smith, RIP.

[Patrick W. Gilmore]

Would like to add my name to the very (very, very, very) long list of people 
who respected and will miss Don.

I do not drink coffee, but for this occasion, it feels appropriate to say:
(coffee != sleep) & (!coffee == sleep)

-- 
TTFN,
patrick

> On Jul 23, 2020, at 7:50 PM, Paul Ferguson  wrote:
> 
> I was informed of this earlier today... I’ve known Don for almost all of the 
> 20+ years that he was engaged with this community. I am very sad to hear of 
> his passing.
> 
> Among his many accomplishments, one of the things that always impressed me 
> about Don was that -- in addition to being a good friend and colleague -- he 
> was also no-nonsense expert technical voice of reason and sanity (also a 
> CCIE) and an early volunteer SANS Daily Incident Handler.
> 
> He will be sorely missed.
> 
> - ferg
> 
> 
> On 7/23/20 4:22 PM, Dobbins, Roland wrote:
> 
>> It is with a heavy heart that I must relate the news that Don Smith, 
>> formerly of CenturyLink and more lately of Netscout Arbor, passed away in 
>> his sleep last night.
>> Don was a colleague, friend, and mentor to many; he was a mainstay of the 
>> operational community, and tirelessly worked to make the Internet safer and 
>> more resilient for us all.  His intellect, wit, and generosity of spirit 
>> were well-known to those who were privileged to have the opportunity to work 
>> with and learn from him.
>> Don’s contributions to the industry were manifold.  While we are all 
>> diminished by his loss, his legacy abides; and we can honor him by 
>> continuing to build upon that foundation, for the betterment of the Internet 
>> community as a whole.
>> Once Don’s family have established plans for his memorial, they will be 
>> posted here.
>> 
>> Roland Dobbins 
> 
> -- 
> Paul Ferguson
> Tacoma, WA  USA
> Illegitimi non carborundum.

Re: Router Suggestions

[Patrick Cole]

Drew,

A 6 Tbps router is a little more expensive than a 2 Tbps router, yes.

I was referring to the 7280SR range not the 7280CR.  

I ended up getting our SR2k's around the same price as MX204's with the help of 
our friendly Arista rep.
MX204's may have gotten chaper in the last year I don't know.  But YMMV.  

-PC

> We've been setting up some Arista DCS-7280CR2K-30-F lately and they have been 
> just OK. The pricing is not at all close to $12,000 though.
> 
> -Drew
>  
> 
> -Original Message-
> From: NANOG  On Behalf Of Patrick Cole
> Sent: Monday, June 15, 2020 8:42 AM
> To: Colton Conor 
> Cc: NANOG 
> Subject: Re: Router Suggestions
> 
> Colton,
> 
> We recently opted for the Arista 7280R2K for peering edge.  They come in at 
> similar price points (maybe a little more?) to the MX204 and are a bit higher 
> capacity.
> 
> Worth a look in.
> 
> Cheers,
> 
> Patrick
> 
> Mon, Jun 15, 2020 at 07:00:55AM -0500, Colton Conor wrote:
> 
> 
> >For around $11,000 right now, you can get a brand new Juniper MX204
> >router. Alternatively, you can get a used MX240 / MX480 with quad power
> >supplies, redundant quad core RE's, and 2 16X10G MIC cards for around
> >$12,000.
> >My question, is there anything else worth looking at in this price range 
> > /
> >port configuration? Open to both new and used options. Looking to take
> >full BGP routes.Â
> 
> --
> Patrick Cole 
> Principal Engineer
> Spirit Telecom Ltd
> 19-25 Raglan St, South Melbourne VIC 3205
> Desk:0385541391
> Mobile:  0410626630
> 

-- 
Patrick Cole 
Principal Engineer
Spirit Telecom Ltd
19-25 Raglan St, South Melbourne VIC 3205
Desk:0385541391
Mobile:  0410626630

Re: Router Suggestions

[Patrick Cole]

Colton,

We recently opted for the Arista 7280R2K for peering edge.  They come in at
similar price points (maybe a little more?) to the MX204 and are a bit higher 
capacity.

Worth a look in.

Cheers,

Patrick

Mon, Jun 15, 2020 at 07:00:55AM -0500, Colton Conor wrote:


>For around $11,000 right now, you can get a brand new Juniper MX204
>router. Alternatively, you can get a used MX240 / MX480 with quad power
>supplies, redundant quad core RE's, and 2 16X10G MIC cards for around
>$12,000.
>My question, is there anything else worth looking at in this price range /
>port configuration? Open to both new and used options. Looking to take
>full BGP routes. 

-- 
Patrick Cole 
Principal Engineer
Spirit Telecom Ltd
19-25 Raglan St, South Melbourne VIC 3205
Desk:0385541391
Mobile:  0410626630

Re: Google peering in LAX

[Patrick W. Gilmore]

On Mar 2, 2020, at 6:30 PM, Seth Mattinen  wrote:
> On 3/2/20 3:09 PM, Patrick W. Gilmore wrote:
>> Your routers, your decision.
>> But how much traffic are you sending TO Google? Most people get the vast 
>> majority of traffic FROM Google. They send you videos, you send them ACKs. 
>> Does it matter where the ACKs go?
> 
> 
> A customer is complaining that data they're sending is going over a higher 
> latency (longer) path. I don't know what they're doing I don't generally ask 
> why, but they claim it's a problem for whatever they're doing and I don't 
> have a reason to doubt them. It's not youtube.
> 
> I agree that it's an undesirable long term solution but if filtering select 
> transit-only /24's shifts the path to peering and reduces latency, if the 
> customer is happy then I'm happy and if/when Google starts accepting peering 
> requests again I'll revisit it.

Again, your routers, your decision. But if I had a customer who was 
complaining, I would take steps to fix it.

Google is sending you prefixes over the IX. You have every right to send them 
traffic over the IX to those prefixes.

That said, I fear this is going to be a problem long term. A blind “no /24s” 
filter is dangerous, plus it might solve all traffic issues. It is going to 
take effort to be sure you don’t get bitten by the Law Of Unintended 
Consequences.

Good luck.

-- 
TTFN,
patrick

Re: Google peering in LAX

[Patrick W. Gilmore]

On Mar 2, 2020, at 17:38, Seth Mattinen  wrote:
> On 3/2/20 2:20 PM, Hugo Slabbert wrote:
>> I believe Owen was referring here to Google's actions: that the disagg is 
>> the antisocial behaviour and that transit providers (the people they are 
>> paying) would be more tolerant of that antisocial behaviour than would be 
>> peers (the people they are not paying).
> 
> 
> I suppose that one went over my head.
> 
> To clarify I am the one with peering in LAX and I'm only seeing the big 
> aggregates via the Any2 Easy servers. At the moment I can only infer that 
> Google announces aggregates to the route servers and maybe one only gets the 
> /24's after you turn up a direct neighbor or PNI, but there's no way to do 
> that since Google isn't accepting new peering requests and steers such 
> requests back to what's available on route servers.
> 
> I suppose what I could do is filter /24's from 15169$ in the absence of being 
> able to see if a direct/PNI peering would include them where route servers do 
> not.

Your routers, your decision.

But how much traffic are you sending TO Google? Most people get the vast 
majority of traffic FROM Google. They send you videos, you send them ACKs. Does 
it matter where the ACKs go?

-- 
TTFN,
patrick

Re: idiot reponse

[Patrick Schultz]

I've also seen employees leaving companies and their addresses being rerouted 
to the support mailbox.

-- 
Patrick

Am 27.02.2020 um 01:25 schrieb Mark Rousell:
> On 26/02/2020 16:24, Randy Bush wrote:
>> act...@nanog.org seems to no longer exist.  how should i be whining
>> about the following?
>>
>> From: Electric Forest Festival 
>> Subject: Forest HQ Has Received Your Message: Re: Hi-Rise Building Fiber 
>> Suggestions
>> To: ra...@psg.com
>> Date: Wed, 26 Feb 2020 16:15:25 +
>>
>>   Electric Forest 2020 will take place on June 25-28, 2020.   Forest HQ has 
>> received your email. Help save precious resources by reviewing the 
>> information below and looking up common questions in The Forest Frequently 
>> Asked Questions: Experience.ElectricForestFestival.com  Please contact 
>> Festival Ticketing Support at 855-279-6941 for all issue regarding your 
>> purchase or for account troubleshooting.  Electric Forest is sold out. Lyte 
>> is the only HQ endorsed way to get passes now that it’s sold out.  To know 
>> when all things Electric Forest 2020 are happening sign up to the EF 
>> Newsletter.  Happy Forest!  
>
> This (or what it appears to be) is happening on an increasing number of mail 
> lists. It's not many but it's there I don't know who is behind it or why, but 
> it's an increasing annoyance.
>
> This is a quick summary of what seems to be happening:
> (1) A legitimate company's or organisation's helpdesk email address is signed 
> up to a mail list like this one.
> (2) Every time someone posts to the list, they receive an automated 
> notification from the helpdesk.
> (3) On mail lists where DMARC mitigation is in effect, the notification comes 
> back to the mail list.
> (4) A consistent pattern is that the helpdesk staff seem utterly incapable of 
> unsubscribing themselves from the list. They always seem to need to be 
> unsubscribed by a list admin.
>
> The key question to my mind is how do these helpdesks get signed up at all? 
> Presumably it's not the helpdesk staff themselves signing them up. It would 
> appear that someone, somewhere has found a vulnerability in Mailman (as far 
> as I can recall I've only
> seen this on Mailman lists) and is intentionally signing up legitimate 
> company helpdesks to mail lists.
>
> Lists with an active admin/mod can fix the problem quickly by unsubscribing 
> the helpdesk.
>
> Is it an attempted (rather feeble) DoS on the mail lists affected, on the 
> concept of a mail list, or on the companies affected? I don't know. I can't 
> see any real point to it. But it's happening.
>
>
>
> -- 
> Mark Rousell

Re: Geo locate change for IP ?

[Patrick Schultz]

Hey Jason,
try the geo database providers first: 
http://thebrotherswisp.com/index.php/geo-and-vpn/

-- 
Patrick

Am 08.01.2020 um 18:53 schrieb JASON BOTHE via NANOG:
> Hi guys
>
> Something odd has happened and I’m not sure how to sort. One of our public 
> prefixes, 205.174.3.0/24 issued from ARIN has suddenly had its geo changed 
> and now everyone accessing the internet from it is showing up as a UK IP, 
> London specifically. We announce this and every other prefix we have out all 
> of our peers globally and are pretty mystified on how this happened and how 
> to resolve. Any help is appreciated. 
>
> Thanks
>
> Jason 

Re: Software Defined Networks

[Patrick W. Gilmore]

I tell everyone we had SDNs in the 90s.

But we called it “expect scripts”.

:-)

-- 
TTFN,
patrick


> On Dec 4, 2019, at 9:41 PM, Jennifer Rexford  wrote:
> 
> SDN is definitely an overloaded and confusing term that is used 
> inconsistently.  Here are a few attempts to explain:
> 
> - “The Road to SDN: An Intellectual History of Programmable Networks” (ACM 
> Queue, December 2013)
>   https://queue.acm.org/detail.cfm?id=2560327 
> <https://queue.acm.org/detail.cfm?id=2560327>
> 
> - “Abstractions for Software-Defined Networks” (CACM, October 2014)
>http://www.cs.cornell.edu/~jnfoster/papers/sdn-abstractions.pdf 
> <http://www.cs.cornell.edu/~jnfoster/papers/sdn-abstractions.pdf>
> 
> - “From Ethane to SDN and Beyond” (ACM SIGCOMM CCR, October 2019)
>https://ccronline.sigcomm.org/wp-content/uploads/2019/10/acmdl19-347.pdf 
> <https://ccronline.sigcomm.org/wp-content/uploads/2019/10/acmdl19-347.pdf>
> 
> — Jen
> 
> 
>> On Dec 4, 2019, at 12:56 PM, Rod Beck > <mailto:rod.b...@unitedcablecompany.com>> wrote:
>> 
>> Can someone explain what is all the fuss? SDN is like the latest telecom 
>> craze but the articles do a poor job of explaining the advantages. I seek 
>> concrete examples. 
>> 
>> Regards, 
>> 
>> Roderick. 
>> 
>> 
>> Roderick Beck
>> VP of Business Development
>> United Cable Company
>> www.unitedcablecompany.com <http://www.unitedcablecompany.com/>
>> New York City & Budapest
>> rod.b...@unitedcablecompany.com <mailto:rod.b...@unitedcablecompany.com>
>> 36-70-605-5144
> 

HPE SAS Solid State Drives - Critical Firmware Upgrade Required

[Patrick W. Gilmore]

I do not normally post about firmware bugs, but I have this nightmare scenario 
running through my head of someone with a couple of mirrored HPE SSD arrays and 
all the drives going POOF!  simultaneously. Even with an off-site backup, that 
could be disastrous. So if you have HPE SSDs, check this announcement.

https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-a00092491en_us

-- 
TTFN,
patrick

Re: Level(3) DNS Spoofing All Domains

[Patrick Schultz]

Just to weigh in: Here in Germany, the largest internet provider (Deutsche 
Telekom) did the same thing.
It's basically just a "search guide", it redirects you to a search page and 
assumes you just had a typo in the URL.

Telekom stopped doing that in April, after a user reported them to the district 
attorney for supposed data manipulation, a misdemeanor.

Am 18.11.2019 um 18:45 schrieb Marshall, Quincy:
> This is mostly informational and may have already hit this group. My 
> google-foo failed me if so.
> 
>  
> 
> I discovered that the CenturyLink/Level(3) public DNS (4.2.2.2, etc) are 
> spoofing all domains. If the hostname begins with a “w” and does not exist in 
> the authoritative zone these hosts will return two Akamai hosts.
> 
>  
> 
> [root@localhost ~]# dig +short w3.dummydomaindoesntexist.gov @4.2.2.2
> 
> 23.202.231.167
> 
> 23.217.138.108
> 
> [root@localhost ~]# dig +short w3.dummydomaindoesntexist.net @4.2.2.2
> 
> 23.202.231.167
> 
> 23.217.138.108
> 
> [root@localhost ~]# dig +short w3.dummydomaindoesntexist.com @4.2.2.2
> 
> 23.202.231.167
> 
> 23.217.138.108
> 
> [root@localhost ~]# dig +short w3.dummydomaindoesntexist.org @4.2.2.2
> 
> 23.202.231.167
> 
> 23.217.138.108
> 
>  
> 
> My apologies if this is old news.
> 
>  
> 
> *Lawrence Q. Marshall*
> 
>  
> 
> 
> 
> ---
> This email has been scanned for email related threats and delivered safely by 
> Mimecast.
> For more information please visit http://www.mimecast.com 
> 
> ---

Multihomed route visibility

[Boyle, Patrick via NANOG]

We are advertising the same prefix to ISP A & ISP B. When looking at various 
route servers across the world, I always see the path through ISP A in the BGP 
table, but most don't show a path at all through ISP B (some do, like Oregon 
IX). I would expect any router with the full table to show both routes. Is this 
a consequence of how the route servers are peered up? Are they only displaying 
the preferred path? ISP Issue? Am I missing something?

Any help would be appreciated.

Patrick Boyle Data Center Architect / Engineer
Network Solutions Architecture and Engineering Section | Network Technology 
Services Bureau
SITSD/Montana Department of Administration
406.444.2549 (D)

SERVICE FIRST!

Submit an 
Incident<https://montana.service-now.com/sp/?id=sc_category_id=e15706fc0a0a0aa7007fc21e1ab70c2f>
 | Search our Knowledge Base<https://montana.service-now.com/sp/?id=kb_view2> | 
Request a Service<https://montana.service-now.com/sp/?id=sc_home>

Re: This endless pissing contest is operational, how? Re: Elad Cohen

[Patrick W. Gilmore]

On Sep 19, 2019, at 9:08 AM, John Sage  wrote:
> 
> On 9/19/19 3:25 AM, Elad Cohen wrote:
>> Mr. Ronald Guilmette
> 
> Are there *any* moderators #OnHere at all?

Moderators? No. Anyone subscribed to the list can post anything at any time.

But posts are reviewed after the fact if there is suspicion or accusations of 
AUP violation.

That is not a real-time process. Give them a day or so.

In the mean time, may I suggest procmail (or whatever your MTA/MUA's filtering 
system is called)?

-- 
TTFN,
patrick

Re: Cogent sales reps who actually respond

[Patrick W. Gilmore]

On Sep 17, 2019, at 9:46 PM, Christopher Morrow  wrote:
> On Tue, Sep 17, 2019 at 6:46 PM Martijn Schmidt via NANOG
>  wrote:
>> 
>> Hi Elad,
>> 
>> Is this policy officially documented by AFRINIC somewhere? Can you make 
>> route objects for legacy AFRINIC resources in their RIR operated IRRDB as a 
>> fallback for RPKI?
>> 
>> Best regards,
>> Martijn 
>> From: Elad Cohen 
>> Sent: 18 September 2019 00:40:13
>> To: Martijn Schmidt ; nanog@nanog.org 
>> 
>> Subject: Re: Cogent sales reps who actually respond
>> 
>> Hello Martin, unfortunately RPKI is not yet technically possible for a 
>> legacy range in Afrinic.
>> _
> 
> technically possible to transfer your afrnic space to ripe though,
> right? and do rpki there.

I do not believe so.

AFRINIC has no inter-RIR transfer policy. I do not believe the fact it is 
legacy space matters, AFRINIC won’t let you move it out, and RIPE wouldn’t let 
you bring it in anyway - AFAIK.

They are the only RIR that does not have an inter-RIR policy. Well, LACNIC just 
voted one in, but it is not implemented - yet.

-- 
TTFN,
patrick

Re: Weekly Routing Table Report

[Patrick W. Gilmore]

The hope is the v6 DFZ will not grow nearly as fast because of far less 
fragmentation.

But who knows?

Also, even today TCAM ain’t cheap. Let’s hope it those numbers are not 
“nothing”.

-- 
TTFN,
patrick

> On Aug 30, 2019, at 4:33 PM, Romeo Czumbil  <mailto:romeo.czum...@tierpoint.com>> wrote:
> 
> These numbers are nothing. Wait till IPv6 really start taking off.
> 
> 
> -Original Message-
> From: NANOG mailto:nanog-boun...@nanog.org>> On 
> Behalf Of Patrick W. Gilmore
> Sent: Friday, August 30, 2019 3:09 PM
> To: North American Operators' Group mailto:nanog@nanog.org>>
> Subject: Re: Weekly Routing Table Report
> 
> A very long time ago, I commented on this report hitting 250,000 prefixes. It 
> was a Big F*#@$&! Deal at the time. A quarter million prefixes in the DFZ? 
> Wow….
> 
> Then I did it again at 500,000. People commented that I should have waited 
> for 512,000 - especially since a popular piece of kit was expected to fall 
> over at 512K prefixes. But I said I liked round numbers.
> 
> This time I waited for 768,000. (Everyone happy now?)
> 
> To say “the Internet grew more than anyone expected” is beyond cliché these 
> days, but that does not make it any less true. The Internet has transformed 
> from a curiosity into something my son[*] and a good portion of his entire 
> generation cannot conceive of living without. A great many people on this 
> list had a part in making all that happen.
> 
> Stop and think about that for a second. You had a part in literally changing 
> the world.
> 
> It is a 3-day weekend in the US. A good time to pause for a few minutes and 
> consider what all of us accomplished together. Pat yourselves on the back, 
> raise a glass or whatever your personal traditions are, and bask in the glory 
> of a job well done.
> 
> --
> TTFN,
> patrick
> 
> [*] The fact I can say “my son” is probably even more amazing. But that is a 
> different story.
> 
> 
>> On Aug 30, 2019, at 2:04 PM, Routing Analysis Role Account > <mailto:csc...@apnic.net>> wrote:
>> 
>> This is an automated weekly mailing describing the state of the 
>> Internet Routing Table as seen from APNIC's router in Japan.
>> 
>> The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG 
>> TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.
>> 
>> Daily listings are sent to bgp-st...@lists.apnic.net 
>> <mailto:bgp-st...@lists.apnic.net>
>> 
>> For historical data, please see 
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.net=DwIFaQ=QbKJOwLIrSFJ6b5qo-Piqw=7c7AjRoUVcwQLzf0TJlbpkDj0XZUiEY9edXj7_CVNLE=maFjVIkqOPdUWLkdE4FI1RUVSfvn9V7rEBtxr4BhRDk=RDK_n-hawo1IaJSf4Q6HI-XszJ3Y2nqjqJIcsPf3tcY=
>>  
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.net=DwIFaQ=QbKJOwLIrSFJ6b5qo-Piqw=7c7AjRoUVcwQLzf0TJlbpkDj0XZUiEY9edXj7_CVNLE=maFjVIkqOPdUWLkdE4FI1RUVSfvn9V7rEBtxr4BhRDk=RDK_n-hawo1IaJSf4Q6HI-XszJ3Y2nqjqJIcsPf3tcY=>
>>  .
>> 
>> If you have any comments please contact Philip Smith > <mailto:pfsi...@gmail.com>>.
>> 
>> Routing Table Report   04:00 +10GMT Sat 31 Aug, 2019
>> 
>> Report Website: 
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.net=DwIFaQ=QbKJOwLIrSFJ6b5qo-Piqw=7c7AjRoUVcwQLzf0TJlbpkDj0XZUiEY9edXj7_CVNLE=maFjVIkqOPdUWLkdE4FI1RUVSfvn9V7rEBtxr4BhRDk=RDK_n-hawo1IaJSf4Q6HI-XszJ3Y2nqjqJIcsPf3tcY=
>>  
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.net=DwIFaQ=QbKJOwLIrSFJ6b5qo-Piqw=7c7AjRoUVcwQLzf0TJlbpkDj0XZUiEY9edXj7_CVNLE=maFjVIkqOPdUWLkdE4FI1RUVSfvn9V7rEBtxr4BhRDk=RDK_n-hawo1IaJSf4Q6HI-XszJ3Y2nqjqJIcsPf3tcY=>
>>  
>> Detailed Analysis:  
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.n 
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.n>
>> et_current_=DwIFaQ=QbKJOwLIrSFJ6b5qo-Piqw=7c7AjRoUVcwQLzf0TJlbpk
>> Dj0XZUiEY9edXj7_CVNLE=maFjVIkqOPdUWLkdE4FI1RUVSfvn9V7rEBtxr4BhRDk=
>> 1SzKtCXB1OQXt_kKzDwHmtLE8a44hKEkYUtraUzC3gI=
>> 
>> Analysis Summary
>> 
>> 
>> BGP routing table entries examined:  768323
>>   Prefixes after maximum aggregation (per Origin AS):  295832
>>   Deaggregation factor:  2.60
>>   Unique aggregates announced (without unneeded subnets):  370810
>> Total ASes present in the Internet Routing Table: 65326
>>   Prefixes per ASN: 11.76
>> Origin-only ASes present in the Internet Routing Table:   

Re: Weekly Routing Table Report

[Patrick W. Gilmore]

A very long time ago, I commented on this report hitting 250,000 prefixes. It 
was a Big F*#@$&! Deal at the time. A quarter million prefixes in the DFZ? Wow….

Then I did it again at 500,000. People commented that I should have waited for 
512,000 - especially since a popular piece of kit was expected to fall over at 
512K prefixes. But I said I liked round numbers.

This time I waited for 768,000. (Everyone happy now?)

To say “the Internet grew more than anyone expected” is beyond cliché these 
days, but that does not make it any less true. The Internet has transformed 
from a curiosity into something my son[*] and a good portion of his entire 
generation cannot conceive of living without. A great many people on this list 
had a part in making all that happen.

Stop and think about that for a second. You had a part in literally changing 
the world.

It is a 3-day weekend in the US. A good time to pause for a few minutes and 
consider what all of us accomplished together. Pat yourselves on the back, 
raise a glass or whatever your personal traditions are, and bask in the glory 
of a job well done.

-- 
TTFN,
patrick

[*] The fact I can say “my son” is probably even more amazing. But that is a 
different story.


> On Aug 30, 2019, at 2:04 PM, Routing Analysis Role Account  
> wrote:
> 
> This is an automated weekly mailing describing the state of the Internet
> Routing Table as seen from APNIC's router in Japan.
> 
> The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG
> TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.
> 
> Daily listings are sent to bgp-st...@lists.apnic.net
> 
> For historical data, please see http://thyme.rand.apnic.net.
> 
> If you have any comments please contact Philip Smith .
> 
> Routing Table Report   04:00 +10GMT Sat 31 Aug, 2019
> 
> Report Website: http://thyme.rand.apnic.net
> Detailed Analysis:  http://thyme.rand.apnic.net/current/
> 
> Analysis Summary
> 
> 
> BGP routing table entries examined:  768323
>Prefixes after maximum aggregation (per Origin AS):  295832
>Deaggregation factor:  2.60
>Unique aggregates announced (without unneeded subnets):  370810
> Total ASes present in the Internet Routing Table: 65326
>Prefixes per ASN: 11.76
> Origin-only ASes present in the Internet Routing Table:   56226
> Origin ASes announcing only one prefix:   24072
> Transit ASes present in the Internet Routing Table:9100
> Transit-only ASes present in the Internet Routing Table:269
> Average AS path length visible in the Internet Routing Table:   4.3
>Max AS path length visible:  45
>Max AS path prepend of ASN ( 27978)  31
> Prefixes from unregistered ASNs in the Routing Table:27
>Number of instances of unregistered ASNs:27
> Number of 32-bit ASNs allocated by the RIRs:  28444
> Number of 32-bit ASNs visible in the Routing Table:   23268
> Prefixes from 32-bit ASNs in the Routing Table:  105688
> Number of bogon 32-bit ASNs visible in the Routing Table:14
> Special use prefixes present in the Routing Table:0
> Prefixes being announced from unallocated address space:288
> Number of addresses announced to Internet:   2834690304
>Equivalent to 168 /8s, 245 /16s and 241 /24s
>Percentage of available address space announced:   76.6
>Percentage of allocated address space announced:   76.6
>Percentage of available address space allocated:  100.0
>Percentage of address space in use by end-sites:   99.3
> Total number of prefixes smaller than registry allocations:  257215
> 
> APNIC Region Analysis Summary
> -
> 
> Prefixes being announced by APNIC Region ASes:   206838
>Total APNIC prefixes after maximum aggregation:   61926
>APNIC Deaggregation factor:3.34
> Prefixes being announced from the APNIC address blocks:  201585
>Unique aggregates announced from the APNIC address blocks:84621
> APNIC Region origin ASes present in the Internet Routing Table:   1
>APNIC Prefixes per ASN:   20.16
> APNIC Region origin ASes announcing only one prefix:   2776
> APNIC Region transit ASes present in the Internet Routing Table:   1483
> Average APNIC Region AS path length visible:   

Re: What can ISPs do better? Removing racism out of internet

[Patrick W. Gilmore]

Cloudflare is not an ISP. They are a CDN. You cannot ask them for a DSL or 
Cable connection, or even DIA.

Not that it matters: ISPs are not “Common Carriers” in statute or Common Law. 
The DMCA provides some protections which are similar to Common Carrier status, 
but that does not mean they have all the rights and responsibilities of Common 
Carriers.

And just to be really meta, that doesn’t matter either. Cloudflare did nothing 
wrong. While in the US, anyone can sue anyone for anything, the idea 8Chan will 
prevail in suing Cloudflare for violation of Common Carrier responsibilities, 
or even for 1st amendment free speech rights, it ludicrous on its face.

I am not terribly pleased with CF’s continued support of miscreants like 
“Booter Services” (read “DDoS-for-Hire”), but their lawyers are not idiots. And 
while you may not believe Anne, I know her and trust her judgement here. Plus I 
know a small amount about running CDNs. So I’m going to go with the consensus 
on the side of “not Common Carriers”. Feel free to disagree. But if you plan to 
convince the people reading this thread, you will have to do better than 
quoting snippets of the DMCA.

-- 
TTFN,
patrick



> On Aug 5, 2019, at 4:19 PM, Mel Beckman  wrote:
> 
> Keith, 
> 
> You’re confusing ISPs that merely provide transport services, such as AT 
> and Cloudfare, with information services like FaceBook and Twitter. The 
> Common Carrier status for legal protection of ISPs stems from the 1998 DMCA, 
> which long preceded the 2015 Network Neutrality act. It provides protection 
> only for an ISP that as a “provider merely acts as a data conduit, 
> transmitting digital information from one point on a network to another at 
> someone else’s request.” The ISP loses that Common Carrier (in the Common Law 
> definition) protection if it alters the transmission in any way.
> 
> Just because an ISP isn’t a Common Carrier under FCC rules doesn’t mean that 
> it isn’t a Common Carrier for other purposes. Trains and planes, for example, 
> are Common Carriers, and the FCC has nothing to do with them. But they can’t 
> exclude passengers based on their speech (yet, anyway). 
> 
> -mel
> 
>> On Aug 5, 2019, at 8:54 AM, Keith Medcalf  wrote:
>> 
>> 
>>> On Monday, 5 August, 2019 09:16, Mel Beckman  wrote:
>>> 
>>> “Now, enough of this off-topic stuff and back to our regularly
>>> scheduled programming.”
>> 
>>> Keith, what could be more on-topic than an ISP’s status as a common
>>> carrier? Seems pretty operational to me.
>> 
>> I think that is closing the barn door after the horse already left.
>> 
>> It is my understanding that in your fabulous United States of America that 
>> "carriers" (meaning having no content serving nor content consuming 
>> customers*) may be "common carriers" or can claim to be common carriers.  
>> The rest of you who are not pure carriers are, thanks to Ijit Pai, merely 
>> Information Services and do not have common carrier status, nor can you 
>> claim to be common carriers.
>> 
>> A "common carrier" is one who must provide carriage provided the fee for 
>> carriage is paid.  This is not the case for "Information Service" providers 
>> as they are not required to provide carriage to any who can pay the fee for 
>> carriage.
>> 
>> *I hate the term "content", it is somowhat lame.
>> 
>> -- 
>> The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
>> lot about anticipated traffic volume.
>> 
>> 
>> 
>> 

Re: User Unknown (WAS: really amazon?)

[Patrick W. Gilmore]

[Speaking ONLY FOR MYSELF AS AN INDIVIDUAL.]

On Aug 4, 2019, at 8:15 AM, Rubens Kuhl  wrote:
> On Sun, Aug 4, 2019 at 5:17 AM Scott Christopher  wrote:
> John Curran wrote: 
> 
> ...
> 
>> As I have noted previously, I have zero doubt in the enforceability of the 
>> ARIN registration services agreements in this regard – so please carefully 
>> consider proposed policy both from the overall community benefit being 
>> sought, and from the implications faced as a number resource holder having 
>> to comply oneself with the new obligations. 
> 
> I completely agree that ARIN can revoke an organization's resources. Nobody 
> has ever doubted that.
> 
> What I have been saying is that if ARIN revoked Amazon's resources because of 
> a trivial matter of bounced Abuse PoC, even if the small "community" of 
> network operators and other interested parties passed a rule supporting this, 
> the backlash would be *enormous* and lead to media attention, litigation, 
> police, investigation by U.S. Congress, etc. 
> 
> The interests of the public affected by a global Amazon/AWS outage would 
> greatly outweigh the rights of this small "community" which would ultimately 
> be stripped away, I'd think.
> 
> This is moot, of course, because ARIN would give ample notices and time to 
> Amazon and they would dutifully comply. But the original poster to which I 
> replied invited us to imagine such a situation.
> 
> 
> 
> I don't think that "companies with tons of lawyers" should be a factor in 
> making resource allocation policies. But considering either small or big 
> networks, an escalation path would reduce friction and increase overall 
> compliance... for instance, failure to have functioning abuse PoC could lead 
> first to being inegible to receive new resources. 

I would love for “companies with tons of lawyers” to be irrelevant to policy 
creation and implementation.

However, ARIN has to exist to enforce policy and support the community. If 
there is an existential threat to the corporation, e.g. legal risks, that must 
be taken into account.

To be clear, this does not mean a company with lots of lawyers should be 
allowed to direct policy. ARIN’s policies should and do come from the 
communities and their elected representatives (the AC). But to say that ARIN 
should not consider the legal implications goes a bit too far, IMHO.

[Reminder: Speaking ONLY FOR MYSELF AS AN INDIVIDUAL.]

-- 
TTFN,
patrick

Re: What can ISPs do better? Removing racism out of internet

[Patrick W. Gilmore]

Mel:

My understanding is ISPs are not Common Carriers. Didn’t we just have a big 
debate about this w/r/t Network Neutrality? I Am Not A Lawyer (hell, I am not 
even an ISP :), but if any legal experts want to chime in, please feel free to 
educate us.

Put another way, ISPs are not phone companies. Moreover, ISPs - and CDNs and 
hosting providers and etc. - can have terms of service which do not allow 
certain types of content on their platform. Again, that is is my understanding. 
Happy to be educated by someone who specializes in this type of law. I know 
there are a couple such people on NANOG-l.

-- 
TTFN,
patrick

P.S. Interesting choice equating a group founded on the principals that “Nazis 
are bad” and a group espousing Nazi ideas. But that’s very off-topic, so if you 
want to discuss, please do so directly.


> On Aug 5, 2019, at 11:13 AM, Mel Beckman  wrote:
> 
> Mehmet,
> 
> I’m not sure if you understand the terms under which ISPs operate as “common 
> carriers”, and thus enjoy immunity from lawsuits due to the acts of their 
> customers. ISPs such as Cloudfare can no more disconnect customers for legal, 
> if offensive, content than the phone company can, without losing that common 
> carrier status.
> 
> Cloudfare is being foolish, and hypocritical. They freely, for example, carry 
> the equally offensive content of Antifa. Are they going to cut them off too?
> 
> In America we have the right to free speech, and the right to use common 
> carriers to carry that speech. If a common carrier chooses to censor legal 
> speech, which is what Cloudfare has done, then it loses its CC status and can 
> now be sued for that speech.
> 
> -mel beckman
> 
>> On Aug 5, 2019, at 8:06 AM, Keith Medcalf  wrote:
>> 
>> 
>>> On Sunday, 4 August, 2019 21:41, Mehmet Akcin  wrote:
>>> 
>>> Most of us who operate internet services believe in not being the
>>> moderator of internet. We provide a service and that’s it. Obviously
>>> there are some established laws around protecting copyrights, and
>>> other things which force us to legally take action and turn things
>>> down when reported.
>> 
>>> What can we do better as network operators about hate sites like
>>> 8Chan?
>> 
>>> I applaud cloudflare’s (perhaps slightly late) decision on kicking
>>> 8chan off its platform today after El Paso attack.
>>> https://blog.cloudflare.com/terminating-service-for-8chan/
>> 
>>> I am sure there are many sites like this out there, but could network
>>> operators do anything to make these sites “not so easy” to be found,
>>> reached, and used to end innocent lives?
>> 
>> I do not quite understand this.  
>> 
>> In days of yore, nutters used to send their screeds to Newspapers, TV and 
>> Radio stations.  Did you shut them down or move them to frequencies that 
>> could not be received with COTS TVs and Radios?  Did you ban the newspapers, 
>> put them out of business, or make it so their broadsheet was only available 
>> by travelling by aeroplane for 8 hours before breakfast?
>> 
>> Of course not, you silly duck!
>> 
>> There is an advantage to having all the nutters congregating on one place -- 
>> you know exactly where to find them.  Granted, the advantage is not exactly 
>> the same as we apply to politicians (or lawyers) who are kepts all in one 
>> place so that kinetic weapons can dispatch the whole lot at one go if 
>> necessary.
>> 
>> However, your solution of sweeping things you do not like under the rug is 
>> ill-conceived if not brain-dead in conception and you must not be permitted 
>> to carry out your objectives.  The fate of the free world depends on it.
>> 
>> However, do not worry.  US AG William Barr is doing a fine job deploying his 
>> "backdoors".  Why just the other day one of them was used to shut down the 
>> Georgia State Public Safety Services, and prior to that his "backdoors" were 
>> used to shut down several city computer systems in Florida and even the City 
>> of Baltimore.  Good work with those backdoors, Mr. Barr.  Job well done!
>> 
>> It is nincompoops who do not think about what they are doing that create 
>> such a bloody mess of things.  They should let the adults take care of it.
>> 
>> Now, enough of this off-topic stuff and back to our regularly scheduled 
>> programming.
>> 
>> -- 
>> The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
>> lot about anticipated traffic volume.
>> 
>> 
>> 
>> 
>> 

Ztomy.com again?

[Patrick]

Anyone else seeing DNS oddities from info.net / infonet.com ?

fwdrev() {
  for ip in `dig +short A $1 @$2`; do
echo $ip `dig +short -x $ip @$2`
  done
}

fwdrev smtp.microsoft.com 8.8.8.8
131.107.115.215 smtp.microsoft.com. mailb.microsoft.com. mail2.microsoft.com.
131.107.115.214 mailc.microsoft.com. mail3.microsoft.com. smtp.microsoft.com.
205.248.106.64 ns1327.ztomy.com.
205.248.106.30 ns1327.ztomy.com.
205.248.106.32 ns1327.ztomy.com.
131.107.115.212 smtp.microsoft.com. mail1.microsoft.com.

fwdrev smtp.microsoft.com 1.1.1.1
205.248.106.30 ns1327.ztomy.com.
205.248.106.32 ns1327.ztomy.com.
205.248.106.64 ns1327.ztomy.com.
131.107.115.212 smtp.microsoft.com. mail1.microsoft.com.
131.107.115.214 mailc.microsoft.com. smtp.microsoft.com. mail3.microsoft.com.
131.107.115.215 mailb.microsoft.com. smtp.microsoft.com. mail2.microsoft.com.


dig +trace -x 205.248.106.30
...

248.205.in-addr.arpa.   86400   IN  NS  dns1.info.net.
248.205.in-addr.arpa.   86400   IN  NS  dns1.infonet.com.
248.205.in-addr.arpa.   86400   IN  NS  dnseur.info.net.
;; Received 360 bytes from 193.0.9.10#53(arin.authdns.ripe.net) in 179 ms

30.106.248.205.in-addr.arpa. 300 IN PTR ns1327.ztomy.com.
;; Received 86 bytes from 208.91.197.27#53(dns1.infonet.com) in 217 ms



Patrick

Re: Intermittent "bad gateway"

[Patrick Schultz]

citing https://www.cloudflarestatus.com/
>Cloudflare has implemented a fix for this issue and is currently monitoring 
>the results

Seems to be a CloudFlare hiccup.

Am 02.07.2019 um 16:16 schrieb Stephen Satchell:
> Are we having another BGP problem this morning?

Are network operators morons? [was: CloudFlare issues?]

[Patrick W. Gilmore]

[Removing the attribution, because many people have made statements like this 
over the last day - or year. Just selecting this one as a succinct and recent 
example to illustrate the point.]

>> This blog post, and your CEO on Twitter today, took every opportunity to say 
>> “DAMN THOSE MORONS AT 701!”.
> Damn those morons at 701, period.

I must be old. All I can think is Kids These Days, and maybe Get Off My BGP, er 
Lawn.

Any company running a large, high complex infrastructure is going to make 
mistakes. Period.

It is not like 701 is causing problems every week, or even ever year. If you 
think this one incident proves they are ‘morons’, you are only showing you are 
neither experienced nor mature enough to make that judgement.

To be clear, they may well be morons. I no longer know many people architecting 
and operating 701’s backbone, so I cannot tell you first-hand how smart they 
are. Maybe they are stupid, but exceptionally lucky. However, the facts at hand 
do not support your blanket assertion, and making it does not speak well of you.

OTOH, I do have first-hand experience with previous CF blog posts, and to say 
they spin things in their favor is being generous. But then, it’s a blog post, 
i.e. Marketing. What else would you expect?


I know it is anathema to the ethos of the network engineers & architects to 
work together instead of hurling insults, but it would probably result in a 
better Internet. And isn’t that what we all (supposedly) want?

-- 
TTFN,
patrick

Re: Cost effective time servers

[Patrick]

On 2019-06-20 20:18, Jay Hennigan wrote:
> If you want to go really cheap and don't value your time, but do value
> knowing the correct time, a GPS receiver with a USB interface and a
> Raspberry Pi would do the trick.

https://www.ntpsec.org/white-papers/stratum-1-microserver-howto/

RPi + GPS Hat because time across USB has much jitter.


Patrick

Re: Google weird routing?

[Patrick Schultz]

Seems to be more end-user oriented rather than targeted at netadmins.
There's no real contact to the GeoIP team besides the peering portal and that 
form, except maybe the NOC. (at least none I found yet)

Am 23.05.2019 um 23:23 schrieb Ross Tajvar:
> Yeah, that's honestly a pretty crappy form. No room for an explanation, no 
> individual contact, and an ETR of a month. I'm surprised there's not a better 
> way to address issues like this 
> 
> On Thu, May 23, 2019, 5:13 PM Matt Harris  <mailto:m...@netfire.net>> wrote:
> 
> On Thu, May 23, 2019 at 4:01 PM Patrick Schultz  
> wrote:
> 
> https://support.google.com/websearch/contact/ip/
> 
> 
> Thanks!  
> 
> Giving that a shot.  It's still loading www.google.com 
> <http://www.google.com> though if I try to hit it in a browser (not 
> redirecting to a different language/CCTLD specific site though) so I had to 
> put that in along with that I'm in the US, not sure
> that whoever sees that form will understand my issue and there's no 
> freeform comments section to mention "but it's loading from India!" 
> 

Re: Google weird routing?

[Patrick Schultz]

https://support.google.com/websearch/contact/ip/

Am 23.05.2019 um 22:55 schrieb Matt Harris:
> On Thu, May 23, 2019 at 3:24 PM Filip Hruska  > wrote:
>
> Google maintains their own GeoIP database. If you peer with them and have 
> access to the peering portal, you can correct the location yourself.
> Otherwise they have a public form somewhere.
>
> --- Filip
>
>
> Googling around a bit does not yield results for that form... any chance 
> anyone here has a link to that?  Would be much appreciated!  
>
> Thanks,
> Matt
>  

Re: Cisco Crosswork Network Insights - or how to destroy a useful service

[Patrick McEvilly]

 

 

 

https://honestnetworker.net/2019/01/31/recent-bgpmon-net-announcement/

 

 

From: NANOG  on behalf of 
Mike Hammett 
Date: Wednesday, May 15, 2019 at 8:35 AM
To: Hank Nussbacher 
Cc: "nanog@nanog.org" 
Subject: Re: Cisco Crosswork Network Insights - or how to destroy a useful 
service
Resent-From: Patrick McEvilly 

 

Cisco ruins everything they touch.



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

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

 

From: "Hank Nussbacher" 
To: nanog@nanog.org
Sent: Wednesday, May 15, 2019 4:50:10 AM
Subject: Cisco Crosswork Network Insights - or how to destroy a useful service

I have started to use Cisco Crosswork Network Insights which is the replacement 
for BGPmon and I am shocked at how Cisco has managed to destroy a useful tool.  
I have had a paid 50 prefix account since the day BGPmon became available and 
helped two clients implement a 500 prefix license over the past 4 years.  None 
will be buying Cisco Crosswork Network Insights, based on my recommendation.

I really don’t know where to begin since there is so much to dislike in this 
new GUI.  I will try to give you just a small taste but I suggest you request a 
90 day trial license and try it out for yourself.

This was not designed by someone who deals with BGP hijacks or who manages a 
network.  It was probably given to some GUI developer with a minimal 
understanding of what the users needed.   How do I know this?  Take for example 
the main configuration menu: https://crosswork.cisco.com/#/configuration with 
the first tab of “prefixes”.  On that page there is no mention of which ASN the 
prefix is associated with.  That of course was fundamental in the BGPmon menu: 
https://portal.bgpmon.net/myprefixes.php

Or take for example its “express configuration”, where you insert an ASN and it 
automatically finds all prefixes and creates a policy.  But does it know the 
name of the ASN?  Nope.  Something again that was basic in BGPmon via: 
https://portal.bgpmon.net/myasn.php is non-existent in CNI.

Or how about the alarms one gets to an email?  Want to see how that looks?

From: Crosswork Admin [mailto:ad...@crosswork.cisco.com] 
Sent: 15 May 2019 11:39
To: Hank Nussbacher 
Subject: CCNI Notification

Active alarm count 1 starting at 2019-05-15 08:34:42.960762315 + UTC. 
Please click on the link for each alarm below: 

https://crosswork.cisco.com/#/alarm/ba7c5084-f05d-4c12-a17f-be9e815d6647

Compare that with what we used to get:

 


Possible Prefix Hijack (Code: 10)


Your prefix:  99.201.0.0/16:
Prefix Description:   Kuku net
Update time:  2018-08-12 17:50 (UTC)
Detected by #peers:   140
Detected prefix:  99.201.131.0/24
Announced by: AS46 (BGP hijacking Ltd)
Upstream AS:  AS11 (Clueless ISP allowing customer hijacking Ltd)
ASpath:   55 44 33 11 46
Alert details:    
https://portal.bgpmon.net/alerts.php?details_id=830521190
Mark as false alert:  https://portal.bgpmon.net/fp.php?aid=830521190

That is just a small sampling.  Maybe two years down the road, Cisco will speak 
to customers first before destroying a useful service.

Anyone else trying this out and feels the same or feels differently?

Disappointed,
Hank

 

 

Re: Widespread Firefox issues

[Patrick Schultz]

or use the hotfix without restarting: 
https://storage.googleapis.com/moz-fx-normandy-prod-addons/extensions/hotfix-update-xpi-intermediate%40mozilla.com-1.0.2-signed.xpi

Am 04.05.2019 um 19:46 schrieb Randy Bush:
>>> to do it, i have to start ffox.  and 100 tabs will open and
>>> javascript will flood in.
> recipe
>   - turn off internet connectivity
>   - start firefox
>   - `kill -s sigkill` it
>   - restart it, do not restore sesstion
>   - turn internet back on
>   - go to prefs / privacy and enable studio
>   - wait until `about:studies` shows you got the two updates
>   - allow sessions to restart
>
> randy

Re: looking for hostname router identifier validation

[Patrick W. Gilmore]

Automation isn’t even that hard - just outsource (e.g. 6Connect).

I get why some things stagnate & collect kruft. But it is actually EASIER, and 
probably cheaper (including people time), to have a 3rd party “just do it” when 
it comes to things like DNS & IPAM.

Then again, if everyone ran everything perfectly … oh, then I could retire. :-)

-- 
TTFN,
patrick



> On Apr 30, 2019, at 8:12 AM, Jared Mauch  wrote:
> 
> While at NTT and at Akamai we have managed to publish sane PTR records and 
> make the forward work as well. You need to automate it by pulling from your 
> router configuration database and publish to your DNS database. If you are 
> still doing either by hand then it’s time to make the switch ASAP. 
> 
> Sent from my iCar
> 
> On Apr 29, 2019, at 4:13 PM, Eric Kuhnke  <mailto:eric.kuh...@gmail.com>> wrote:
> 
>> I would caution against putting much faith in the validity of geolocation or 
>> site ID by reverse DNS PTR records. There are a vast number of unmaintained, 
>> ancient, stale, erroneous or wildly wrong PTR records out there. I can name 
>> at least a half dozen ISPs that have absorbed other ASes, some of those 
>> which also acquired other ASes earlier in their history, forming a turducken 
>> of obsolete PTR records that has things with ISP domain names last in use in 
>> the year 2002.
>> 
>> 
>> 
>> On Mon, Apr 29, 2019 at 6:15 AM Matthew Luckie > <mailto:m...@luckie.org.nz>> wrote:
>> Hi NANOG,
>> 
>> To support Internet topology analysis efforts, I have been working on
>> an algorithm to automatically detect router names inside hostnames
>> (PTR records) for router interfaces, and build regular expressions
>> (regexes) to extract them.  By "router name" inside the hostname, I
>> mean a substring, or set of non-contiguous substrings, that is common
>> among interfaces on a router.  For example, suppose we had the
>> following three routers in the savvis.net <http://savvis.net/> domain 
>> suffix, each with two
>> interfaces:
>> 
>> das1-v3005.nj2.savvis.net <http://das1-v3005.nj2.savvis.net/>
>> das1-v3006.nj2.savvis.net <http://das1-v3006.nj2.savvis.net/>
>> 
>> das1-v3005.oc2.savvis.net <http://das1-v3005.oc2.savvis.net/>
>> das1-v3007.oc2.savvis.net <http://das1-v3007.oc2.savvis.net/>
>> 
>> das2-v3009.nj2.savvis.net <http://das2-v3009.nj2.savvis.net/>
>> das2-v3012.nj2.savvis.net <http://das2-v3012.nj2.savvis.net/>
>> 
>> We might infer the router names are das1|nj2, das1|oc2, and das2|nj2,
>> respectively, and captured by the regex:
>> ^([a-z]+\d+)-[^\.]+\.([a-z]+\d+)\.savvis\.net$
>> 
>> After much refinement based on smaller sets of ground truth, I'm
>> asking for broader feedback from operators.  I've placed a webpage at
>> https://www.caida.org/~mjl/rnc/ <https://www.caida.org/~mjl/rnc/> that shows 
>> the inferences my algorithm
>> made for 2523 domains.  If you operate one of the domains in that
>> list, I would appreciate it if you could comment (private is probably
>> better but public is fine with me) on whether the regex my algorithm
>> inferred represents your naming intent.  In the first instance, I am
>> most interested in feedback for the suffix / date combinations for
>> suffixes that are colored green, i.e. appear to be reasonable.
>> 
>> Each suffix / date combination links to a page that contains the
>> naming convention and corresponding inferences.  The colored part of
>> each hostname is the inferred router name.  The green hostnames appear
>> to be correct, at least as far as the algorithm determined.  Some
>> suffixes have errors due to either stale hostnames or incorrect
>> training data, and those hostnames are colored red or orange.
>> 
>> If anyone is interested in sets of hostnames the algorithm may have
>> inferred as 'stale' for their network, because for some operators it
>> was an oversight and they were grateful to learn about it, I can
>> provide that information.
>> 
>> Thanks,
>> 
>> Matthew

Re: Special Counsel Office report web site

[Patrick W. Gilmore]

On Apr 17, 2019, at 9:02 PM, Sean Donelan  wrote:
> 
> The Special Counsel's report is expected to be posted on its website sometime 
> between 11 a.m. and noon on Thursday, April 18, 2019.
> 
> https://www.justice.gov/sco
> 
> Since I helped with website for the Starr Report on September 11, 1998, I 
> wish all website admins and network admins well tommorrow morning.
> 
> # config t
> ip go faster

Sean:

I remember “ip go faster” when you first posted it back in 1998. It was 
hilarious, I literally “LOL”ed. However, I did not envy you your job with that 
short notice. (But I did envy you all the people who were willing to help on 
such short notice.) I am still impressed at what you were able to pull together 
in just a few days. Major Kudos.

Things will probably be easier this time. The Internet has evolved ways of 
dealing with exactly this problem. (Avi used to call it “slash-dot insurance”, 
but the idea is the same.) Specifically:

TiggerBook-C-32:~ patrick$ dig +short www.justice.gov
www.justice.gov.edgekey.net.
e7598.dscg.akamaiedge.net.

’Nuff said.

-- 
TTFN,
patrick

Re: Incoming SSDP UDP 1900 filtering

[Patrick McEvilly]

I'm working with Level3 on a similar problem.  They filter both UDP and TCP 
port 1900 on our peer to them.  This is blocking all connections that randomly 
use ephemeral tcp port 1900.

They are refusing to remove the tcp port 1900 filter without dispensation from 
the DDoS security gods. I understand blocking UDP 1900, what is the purpose of 
Level3 filtering tcp port 1900?  


On 3/25/19, 12:44 PM, "NANOG on behalf of Saku Ytti" 
 wrote:

Hey Tom,

> If your edge ingress ACLs are not 100% in sync all the time, you will 
inevitably have Really Weird Stuff happen that will end up taking forever to 
diagnose.

You may at some cases have hard to troubleshoot issues, which is true
for everything, even when perfectly configured, because software is
not perfect. However choosing to do iACL is still something many
networks choose to do, because the upside is worth the complexity to
them.

> Packet filtering is more computationally taxing than just routing is. 
Your edge equipment is likely going to be built for maximum routing efficiency. 
Trying to bite off too much filtering there increases your risk of legit 
traffic being tossed on the floor.

Depends on implementation, on some implementations it is zero-cost on
some it is not. On most implementations it's very cheap, particularly
compared to say uRPF. It seems your position is 'i don't know how ACL
works on my platforms and i don't trust myself to write ACL, so i
should not do them', which is perfectly valid position under those
constrains, but other networks have other constrains under which it is
no longer valid proposal to omit doing iACL.

I would encourage networks to continue deploying iACL and consider it
BCP. iACL removes attack surface and protects you from host of known
and unknown SIRT issues.

-- 
  ++ytti

Re: AT/as7018 now drops invalid prefixes from peers

[Patrick W. Gilmore]

Jay & everyone AT: I just want to say thank you. Kudos to your team for 
implementing and management for having the intestinal fortitude to do so.

-- 
TTFN,
patrick

> On Feb 11, 2019, at 09:53, Jay Borkenhagen  wrote:
> 
> 
> FYI:
> 
> The AT/as7018 network is now dropping all RPKI-invalid route
> announcements that we receive from our peers.  
> 
> We continue to accept invalid route announcements from our customers,
> at least for now.  We are communicating with our customers whose
> invalid announcements we are propagating, informing them that these
> routes will be accepted by fewer and fewer networks over time.
> 
> Thanks to those of you who are publishing ROAs in the RPKI.  We would
> also like to encourage other networks to join us in taking this step
> to improve the quality of routing information in the Internet.
> 
> Thanks!
> 
>   Jay B.
> 
> 

Re: CenturyLink

[Patrick Boyle via NANOG]

Looks like we lost sync intermittently across several of their servers last 
night. Cleared up around midnight mountain for me.

Let's chip in and get some carrier diversity for those guys :)


Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Friday, December 28, 2018 4:23 PM, Yang Yu  wrote:

> On Fri, Dec 28, 2018 at 12:05 AM Stephane Bortzmeyer bortzme...@nic.fr wrote:
>
> > Is this problem also responsible for the 911 outage? If so, the
> > post-mortem analysis is not useful only for CenturyLink customers but
> > for everyone on the west coast.
>
> Looks like mosttime.nist.gov servers (3 x NIST sites on AS49) are
> single homed on CenturyLink, anyone noticed NTP issues yesterday?
>
> https://tf.nist.gov/tf-cgi/servers.cgi

Re: CenturyLink...is being investigated by the FCC

[Patrick Boyle via NANOG]

Ouch. Feel bad for the guys on the ground at C-link. Not a fun 24 hours.


Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Friday, December 28, 2018 3:17 PM, Anne P. Mitchell, Esq. 
 wrote:

> And the other latest news is that the FCC is investigating the CenturyLink 
> outage:
>
> https://www.theinternetpatrol.com/fcc-investigating-centurylink-outage-says-unacceptable/
>
> > On Dec 28, 2018, at 3:11 PM, Patrick Boyle via NANOG nanog@nanog.org wrote:
> > Yes, there were 911 services affected. The latest word from C-link as of 
> > 1:46PM mountain is that all 911 services are restored where they are the 
> > provider. I'm not 100% sure if that's system-wide, or just my area in the 
> > northwest, however.
> > Sent with ProtonMail Secure Email.
> > ‐‐‐ Original Message ‐‐‐
> > On Friday, December 28, 2018 1:03 AM, Stephane Bortzmeyer bortzme...@nic.fr 
> > wrote:
> >
> > > On Fri, Dec 28, 2018 at 07:07:42AM +,
> > > Erik Sundberg esundb...@nitelusa.com wrote
> > > a message of 131 lines which said:
> > >
> > > > CenturyLink will be conducting an extensive post-incident
> > > > investigation and root cause analysis to provide follow-up
> > > > information to our customers
> > >
> > > Is this problem also responsible for the 911 outage? If so, the
> > > post-mortem analysis is not useful only for CenturyLink customers but
> > > for everyone on the west coast.

Re: CenturyLink

[Patrick Boyle via NANOG]

Yes, there were 911 services affected. The latest word from C-link as of 1:46PM 
mountain is that all 911 services are restored where they are the provider. I'm 
not 100% sure if that's system-wide, or just my area in the northwest, however.


Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Friday, December 28, 2018 1:03 AM, Stephane Bortzmeyer  
wrote:

> On Fri, Dec 28, 2018 at 07:07:42AM +,
> Erik Sundberg esundb...@nitelusa.com wrote
> a message of 131 lines which said:
>
> > CenturyLink will be conducting an extensive post-incident
> > investigation and root cause analysis to provide follow-up
> > information to our customers
>
> Is this problem also responsible for the 911 outage? If so, the
> post-mortem analysis is not useful only for CenturyLink customers but
> for everyone on the west coast.

Re: CenturyLink

[Patrick Boyle via NANOG]

Seeing the same from here in Montana. Internet traffic is seeing routing issues 
through them on the circuits that are up.

I’ve heard it’s a widespread DWDM issue. They have crews in Kansas City, New 
Orleans, and Atlanta

Sent from ProtonMail Mobile

On Thu, Dec 27, 2018 at 11:45 AM, Naslund, Steve  wrote:

> Anyone have any insight to the nationwide CenturyLink issues/outages today?  
> Just wondering.  Know for sure that our connections to them from Florida, 
> Iowa, and Washington State are all affected.  Voice and data.
>
> Steven Naslund
>
> Chicago IL

Re: Stupid Question maybe?

[Patrick W. Gilmore]

Why do you think the network portion needs to be contiguous?

Well, it does now. But that was not always the case.

https://www.quora.com/Why-is-the-subnet-mask-255-255-255-64-invalid/answer/Patrick-W-Gilmore
https://www.quora.com/Why-is-the-subnet-mask-255-255-255-64-invalid

-- 
TTFN,
patrick

> On Dec 19, 2018, at 09:54, Naslund, Steve  wrote:
> 
> I am wondering how a netmask could be not contiguous when the network portion 
> of the address must be contiguous.  I suppose a bit mask could certainly be 
> anything you want but a netmask specifically identifies the network portion 
> of an address.
> 
> Steve
> 
>> I seem to remember that before the advent of VLSM and CIDR there was 
>> no requirement for the 1 bits in the netmask to be contiguous with no 
>> intervening 0 bits and there was always someone who tested it out on a 
>> production network just to prove a point (usually only once)

Re: Massive Price Increase for X-conns at Telehouse Chelsea, NYC

[Patrick W. Gilmore]

On Sep 17, 2018, at 17:51, Nick Hilliard  wrote:
> Patrick W. Gilmore wrote on 17/09/2018 22:40:
>> Expecting any for-profit business (all of them, not just REITs) to do
>> less than extract maximum cash is deluding yourself.
> oh sure, but price gouging is often bad business practice in the long term.  
> Humans evolved a strong sense of injustice and have a long memory for people 
> and organisations whom they feel take advantage of them.
> 
> As someone else pointed out, business practices like this can work in a 
> rising market, but not so well when market conditions become difficult and 
> people end up in a position of being able to make a choice between 
> organisations which may have treated them badly in the past and those which 
> have not.

No argument. You cut out part of my reply:

When a business gives you something for free, they are expecting
something in return - return business, personal data, lower
churn, good reviews, customer loyalty, etc. - that they can turn
into cash. Any business with little or no competition can be
expected to raise prices. This is not exactly new or surprising.

If you “s/free/free or lower cost/“, it satisfies your statement as well. Every 
business should be deciding “how much can I make -long term-“, and take into 
account what you, I, and others have said here. Some will think short term, and 
(hopefully) the market will punish them over time.

Anyway, I think everyone on the thread agrees. Xconn fees are higher than they 
should be, but not necessarily higher than the market will bear. Yet.

Besides, once everyone turns up a single 100 Tbps port to PacketFabric (or two 
for redundancy), xconn fees will be irrelevant. :-)

-- 
TTFN,
patrick

Re: Massive Price Increase for X-conns at Telehouse Chelsea, NYC

[Patrick W. Gilmore]

On Sep 17, 2018, at 15:08, Ethan O'Toole  wrote:
> 
>> If it’s in an interduct by itself, how much would the square footage per
>> month occupied by the average cross connect be worth?
> 
> These big datacenter companies are REITs. Similar to self-storage units and 
> apartment buildings, they exist to extract as much money as possible from the 
> users. Nothing more or nothing less. The price relief only comes when the 
> market is grossly overbuilt and if there is actual competition.

Maybe I am confused, but I thought every for-profit business exists to extract 
as much money as possible.

When a business gives you something for free, they are expecting something in 
return - return business, personal data, lower churn, good reviews, customer 
loyalty, etc. - that they can turn into cash. Any business with little or no 
competition can be expected to raise prices. This is not exactly new or 
surprising.

Expecting any for-profit business (all of them, not just REITs) to do less than 
extract maximum cash is deluding yourself.

-- 
TTFN,
patrick

Re: Confirming source-routed multicast is dead on the public Internet

[Patrick W. Gilmore]

It is hard to prove a negative.

So let’s prove a positive. One of the largest (2nd largest?) transit networks 
on the planet just affirmatively stated they filter at their border. It is now 
possible to state that multicast is not ubiquitous on the Internet.

If any other large transit network (L3, GTT, HE, Cogent, etc.) would like to 
confirm they filter at their borders as well, that would put the final nail in 
the coffin.

-- 
TTFN,
patrick

> On Jul 31, 2018, at 15:15, Job Snijders  wrote:
> 
> On Tue, 31 Jul 2018 at 23:29, Sean Donelan  wrote:
> 
>> Its tought to prove a negative. I'm extremely confident the answer is yes,
>> public internet multicast is not viable. I did all the google searches,
>> check all the usual CAIDA and ISP sites. IP Multicast is used on private
>> enterprise networks, and some ISPs use it for some closed services.
>> 
>> I got sent back with a random comment from a senior official saying "but
>> I heard different." I bit my tongue, and said I would double (now
>> quadruple) check.
>> 
>> If any ISPs have working IP source-routed multicast on the public
>> Internet that I missed, or what I got wrong.  That's what content
>> distribution networks (cdn's) are for instead.
> 
> 
> 
> AS 2914 is working to fully dismantle all its Internet multicast related
> infrastructure and configs. All MSDP sessions have been turned off, we have
> deny-all filters for the multicast AFI, and the RPs have been shut down.
> 
> For years we haven’t seen actual legit multicast traffic. Also the
> multicast “Default-Free Zone” has always been severely partitioned. Not all
> the players were peering with each other, which led to significant
> complexity for any potential multicast source.
> 
> Reasoning behind turning it off is that it limits the attack surface
> (multicast can bring quite some state to the core), reduces the things we
> need to test and qualify, and by taking this off the RFPs we can perhaps
> consider more vendors.
> 
> However, as you noted; multicast within a single administrative domain
> (such as an access network distributing linear TV), or confined to
> purpose-built L3VPNs very much is a thing. On the public Internet multicast
> seems dead.
> 
> Kind regards,
> 
> Job

Re: What are people using for IPAM these days?

[Patrick W. Gilmore]

While there are many good options, I prefer 6Connect personally. Lots of hooks 
to let you automate things (not just which device has which IP address, much 
more), cheap as hell, and support is unbeatable.

-- 
TTFN,
patrick

> On Jun 11, 2018, at 10:45, Owen DeLong  wrote:
> 
> I find lots of people are using either 6connect or InfoBlox.
> 
> YMMV. Both have good IPv6 support.
> 
> Owen
> 
> 
>> On Jun 11, 2018, at 07:07 , Steve Mikulasik  
>> wrote:
>> 
>> PHPIpam, but I do find there to be a lack of current documentation.

RE: Gonna be a long day for anybody with CPE that does WPA2..

[Gogan, James Patrick]

Aruba:  http://www.arubanetworks.com/assets/alert/ARUBA-PSA-2017-007.txt

-- Jim Gogan / UNC-Chapel Hill

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Edwin Pers
Sent: Monday, October 16, 2017 8:10 AM
To: Job Snijders ; valdis.kletni...@vt.edu
Cc: nanog@nanog.org
Subject: RE: Gonna be a long day for anybody with CPE that does WPA2..

I see here that MikroTik has patched this about a week ago: 
https://forum.mikrotik.com/viewtopic.php?f=21=126695

Any word on other vendor's response to this?

Ed


-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Job Snijders
Sent: Monday, October 16, 2017 5:14 AM
To: valdis.kletni...@vt.edu
Cc: nanog@nanog.org
Subject: Re: Gonna be a long day for anybody with CPE that does WPA2..

Dear all,

Website with logo: https://www.krackattacks.com/

Paper with background info: https://papers.mathyvanhoef.com/ccs2017.pdf

Kind regards,

Job

Re: Peering at public exchange authentication

[Patrick W. Gilmore]

MD5 on BGP Considered Harmful

-- 
TTFN,
patrick

Composed on a virtual keyboard, please forgive typos. 


> On Sep 29, 2017, at 13:41, craig washington <craigwashingto...@hotmail.com> 
> wrote:
> 
> Hello all,
> 
> 
> Wondering your views or common practices for using authentication via BGP at 
> public exchange locations.
> 
> Just for example, lets say you peer with 5 people in the TELX in Atlanta, do 
> you require them to all use authentication for the BGP session?
> 
> Ive seem some use it and some not use it, is it just a preference?

Hughesnet IPv6

[Patrick Shoemaker]

Are there any HughesNet network engineers on here who could either contact me 
off list to answer some questions about the IPv6 implementation on the Gen5 
platform? Standard support mechanisms are not very useful here.

Thanks,

Patrick Shoemaker

Re: Max Prefix Out, was Re: Verizon 701 Route leak?

[Patrick W. Gilmore]

On Sep 1, 2017, at 5:26 AM, Randy Bush <ra...@psg.com> wrote:
> 
> i have 142 largish bgp customers, a large enough number that the number
> of prefixes i receive from them varies annoyingly.  how do i reasonably
> automate setting of my outbound prefix limit?

First, it seems you know the inbound so automating the outbound is simple 
arithmetic.

But even if that is unruly, setting the outbound to, say, 300K or so would keep 
you from spilling a full table. Not perfect, but better than nothing.

Orr, perhaps this feature is not for you?

-- 
TTFN,
patrick

Re: BGP peering question

[Patrick W. Gilmore]

> Then you need to decide if you want to be a hop between those two peers or if 
> you want them to serve you only. You can change your routing so that both 
> providers know of your routes but you are not sharing routes between the two 
> providers.

The definition of “peering” to most ISPs would definitely not include becoming 
a “hop” between two peers. Most networks would de-peer you if you sent their 
prefixes to another peer.

-- 
TTFN,
patrick

> On Jul 11, 2017, at 2:40 PM, Ethan E. Dee <e...@globalvision.net> wrote:
> 
> Considering the wording you use, I would include this,
> 
> 'Peering' is not always necessary. If you can get an upstream provider to 
> give you a pack of IP's and it is sufficient to just use them as a gateway 
> instead of setting up peering that would be preferred.
> 
> If you decide you want to have multiple upstream providers or hit some kind 
> of speed cap is when I would probably peer with someone else. So that you can 
> keep your IP space but share it across a redundant connection from a 
> different provider.
> 
> Then you need to decide if you want to be a hop between those two peers or if 
> you want them to serve you only. You can change your routing so that both 
> providers know of your routes but you are not sharing routes between the two 
> providers.
> 
> BGP is an enormous protocol and extremely scalable so there is alot to 
> consider before you even decide if you want to peer.
> 
> Because it can sometimes be a headache to setup.
> 
> 
> On 07/11/2017 02:17 PM, Bob Evans wrote:
>> There is one more thing to consider based on your app or content latency
>> criteria needs. Do you provide a service that performs better with low
>> latency - such as live desktop, live video/voice. You may wish to peer to
>> have more control and more direct  path to your customer base. If you
>> identify your customer base in a specific region - then explore the best
>> peering exchange points to utilize in that region. This can help you
>> reduce your packet hop count/ deliver time, etc. etc..
>> 
>> Thank You
>> Bob Evans
>> CTO
>> 
>> 
>> 
>> 
>>> On Mon, Jul 10, 2017 at 4:12 PM, craig washington <
>>> craigwashingto...@hotmail.com> wrote:
>>> 
>>>> Newbie question, what criteria do you look for when you decide that you
>>>> want to peer with someone or if you will accept peering with someone
>>>> from
>>>> an ISP point of view.
>>> 
>>> I assume you mean "reciprocal peering" in the sense of shortcut from your
>>> customers to their customers rather than the more generic sense that any
>>> BGP neighbor is a "peer".
>>> 
>>> 1. What does it cost? If you and they are already on an IX peering switch
>>> or you're both at a relaxed location where running another cable carries
>>> no
>>> monthly fee, there's not much down side.
>>> 
>>> 2. Is the improvement to your service worth the cost? It's not worth
>>> buying
>>> a data circuit or cross-connect to support a 100kbps trickle.
>>> 
>>> 3. Do you have the technical acumen to stay on top of it? Some kinds of
>>> breakage in the peering link could jam traffic between your customers and
>>> theirs. If you're not able to notice and respond, you'd be better off
>>> sending the traffic up to your ISPs and letting them worry about it.
>>> 
>>> If the three of those add up to "yes" instead of "no" then peering may be
>>> smart.
>>> 
>>> Regards,
>>> Bill Herrin
>>> 
>>> 
>>> --
>>> William Herrin  her...@dirtside.com  b...@herrin.us
>>> Dirtside Systems . Web: <http://www.dirtside.com/>
>>> 
>> 
> 
> -- 
> Ethan Dee
> Network Admin
> Globalvision
> 864 704 3600
> e...@globalvision.net
> 
> For Support:
> gv-supp...@globalvision.net
> 864 467 1333
> 
> For Sales:
> sa...@globalvision.net
> 864 467 1333

Re: BGP peering question

[Patrick W. Gilmore]

1) Are they present an IX where I am present?

2) Can they configure BGP correctly?

3) … Beer?

Private interconnect requires actual thinking. Putting a procedure in around 
public peering is just overhead we don’t need.

-- 
TTFN,
patrick

> On Jul 10, 2017, at 4:12 PM, craig washington <craigwashingto...@hotmail.com> 
> wrote:
> 
> Hello,
> 
> 
> Newbie question, what criteria do you look for when you decide that you want 
> to peer with someone or if you will accept peering with someone from an ISP 
> point of view.
> 
> 
> Thanks.
> 
> 

Re: Retarus (AS 48328)

[Patrick Schultz]

Hi Martin,
the only address I can point you at is "support at retarus dot com".
We once had to contact them about a SMTP problem and this was the only working 
contact.

Best,
Patrick

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

Re: 10G MetroE 1-2U Switch

[Patrick Cole]

Sorry, slight correction to the below - GMPLS Sub-TLVs inside the TE LSAs
were being advertised with nil values instead of being removed completely.

One additional thing that really irked me is that their TE code is that
they set all TE metrics to 0 for every interface/link and no way to use
the IGP metric or set it, so if you have two links of equal distance
in terms of hops, there was no way to steer a CSPF computed LSP to prefer 
one without using EROs to do it.  They also have no concept of attribute
flags or link colors.

Ultimately, their TE implementation was very basic. They openly admitted 
their focus was on GMPLS and not MPLS-TE.  For us, GMPLS has no real
use case in our network.

Patrick

Fri, Apr 21, 2017 at 11:45:06PM +1000, Patrick Cole wrote:


> Aaron,
> 
> The code is very green;  the platform originally was inherited from
> Nortel and as such they invested heavily in PBB-TE first and foremost.
> 
> To give you an idea they're currently at version 6.16 and the MPLS 
> code was introduced in 6.10 (from memory).
> 
> They support just enough OSPFv2 or IS-IS to implement basic MPLS TE 
> functionality but it does not interop with any other vendor well
> at all from my testing.
> 
> They only support protected active/standby LSP groups withI maximum
> 2 paths per group.  Paths inside a group cannot be computed automatically
> and /must/ have EROs specified.  
> 
> They do not support Fast Reroute PLR/MP in any way and their product
> manager said they have no plans to do so in the future.  They do support
> "signalling" desired FRR protection on an LSP, however, in my lab testing
> this is a moot point as they don't interop with our Cisco core gear.
> They seem to add GMPLS TLVs in to their PATH msgs with nil values even
> when you aren't using GMPLS, which Cisco doesn't like.
> 
> I was able to get their gear to interop with our Brocade routers, but
> it was world of hurt of problems in production as they don't do make
> before break on LSPs or anything useful like that.
> 
> Even when running only their gear in isolation, we had numerous extremely
> large service impacting problems with their software - things that as
> a software and network engineer by trade I can only put down
> to extremely badly written code. For example we had an issue where when
> BFD would flap on links rapidly through our network, the MPLS cross
> connect table would get misprogrammed with a bad value and then from
> that point onwards all transit LSPs would fail to signal through the
> node.
> 
> Even further to this, the biggest issue I had is that their software 
> was not written with enough easy-to-access diagnostic/debugging capability 
> to be able to allow the vendor to triage and get to the root cause 
> of issues.  Most major issues never got solved because the things
> the vendor required you to troubleshoot were outragously inconvenient
> or massively service affecting in nature.  Example;  there was no
> way to send debugging via the network (syslog etc).  In quite a
> few cases I had to break out in to the linux CLI and run their 
> debug streaming program on all our nodes and use netcat to transport
> it back to our servers to capture it.
> 
> They implement LDP signalled PWE and VPLS but the cli has a lot of
> really annoying nuances like, you can't change the LSP on a pseudowire
> without detaching it from its virtual switch (no make-before-break 
> functionality exists either).
> 
> We stuck with it for a while, hoping it would get better but every
> release seemed to bring different bugs, and the old ones never 
> seemed to get fully fixed and would resurface in the future.  I
> suspect they were dealing with race conditions in their code and
> they just never could seem to reproduce the conditions that would
> cause them in their lab.  I think our microwave network tested their
> code in ways they never had before when storms rolled through.
> 
> This might all be different on their larger packet optical devices
> I don't know - this all applies to the SA-OS on 39XX/51XX platform.
> 
> We now use the ASR920 platform and comparatively it's night and
> day in terms of feature set and stability.  Only thing I'm missing 
> is lack of tunnel byte counters for use by auto-bw, but Cisco say 
> this is coming in Everest...
> 
> Regards,
> 
> Patrick
> 
> 
> Wed, Apr 19, 2017 at 03:06:42PM -0500, Aaron Gould wrote:
> 
> > Oh, ok... hmmm
> > 
> > So what was the issue with Ciena and MPLS Patrick ?
> > 
> > -Aaron
> > 
> > 
> 
> -- 
> Patrick Cole <z...@wwwires.com>
> Senior Network Specialist
> World Without Wires
> PO Box 869. Palm Beach, QLD, 4221
> Ph:  0410 626 630
> 

-- 
Patrick Cole <z...@wwwires.com>
Senior Network Specialist
World Without Wires
PO Box 869. Palm Beach, QLD, 4221
Ph:  0410 626 630

Re: 10G MetroE 1-2U Switch

[Patrick Cole]

Aaron,

The code is very green;  the platform originally was inherited from
Nortel and as such they invested heavily in PBB-TE first and foremost.

To give you an idea they're currently at version 6.16 and the MPLS 
code was introduced in 6.10 (from memory).

They support just enough OSPFv2 or IS-IS to implement basic MPLS TE 
functionality but it does not interop with any other vendor well
at all from my testing.

They only support protected active/standby LSP groups withI maximum
2 paths per group.  Paths inside a group cannot be computed automatically
and /must/ have EROs specified.  

They do not support Fast Reroute PLR/MP in any way and their product
manager said they have no plans to do so in the future.  They do support
"signalling" desired FRR protection on an LSP, however, in my lab testing
this is a moot point as they don't interop with our Cisco core gear.
They seem to add GMPLS TLVs in to their PATH msgs with nil values even
when you aren't using GMPLS, which Cisco doesn't like.

I was able to get their gear to interop with our Brocade routers, but
it was world of hurt of problems in production as they don't do make
before break on LSPs or anything useful like that.

Even when running only their gear in isolation, we had numerous extremely
large service impacting problems with their software - things that as
a software and network engineer by trade I can only put down
to extremely badly written code. For example we had an issue where when
BFD would flap on links rapidly through our network, the MPLS cross
connect table would get misprogrammed with a bad value and then from
that point onwards all transit LSPs would fail to signal through the
node.

Even further to this, the biggest issue I had is that their software 
was not written with enough easy-to-access diagnostic/debugging capability 
to be able to allow the vendor to triage and get to the root cause 
of issues.  Most major issues never got solved because the things
the vendor required you to troubleshoot were outragously inconvenient
or massively service affecting in nature.  Example;  there was no
way to send debugging via the network (syslog etc).  In quite a
few cases I had to break out in to the linux CLI and run their 
debug streaming program on all our nodes and use netcat to transport
it back to our servers to capture it.

They implement LDP signalled PWE and VPLS but the cli has a lot of
really annoying nuances like, you can't change the LSP on a pseudowire
without detaching it from its virtual switch (no make-before-break 
functionality exists either).

We stuck with it for a while, hoping it would get better but every
release seemed to bring different bugs, and the old ones never 
seemed to get fully fixed and would resurface in the future.  I
suspect they were dealing with race conditions in their code and
they just never could seem to reproduce the conditions that would
cause them in their lab.  I think our microwave network tested their
code in ways they never had before when storms rolled through.

This might all be different on their larger packet optical devices
I don't know - this all applies to the SA-OS on 39XX/51XX platform.

We now use the ASR920 platform and comparatively it's night and
day in terms of feature set and stability.  Only thing I'm missing 
is lack of tunnel byte counters for use by auto-bw, but Cisco say 
this is coming in Everest...

Regards,

Patrick


Wed, Apr 19, 2017 at 03:06:42PM -0500, Aaron Gould wrote:

> Oh, ok... hmmm
> 
> So what was the issue with Ciena and MPLS Patrick ?
> 
> -Aaron
> 
> 

-- 
Patrick Cole <z...@wwwires.com>
Senior Network Specialist
World Without Wires
PO Box 869. Palm Beach, QLD, 4221
Ph:  0410 626 630

Re: 10G MetroE 1-2U Switch

[Patrick Cole]

Yes, stay well away from the Ciena MPLS code... based on my experience
with the CN5100/3900 series...

Tue, Apr 18, 2017 at 02:08:05AM +0100, Tom Hill wrote:

> On 13/04/17 23:47, Aaron Gould wrote:
> > Pretty sure I looked at the ciena 51xx and I found that it does not have
> > mpls in it... pretty sure Erik needs mpls...
> 
> The 5150 will 'do MPLS', which is pretty clear from their website. The
> references 5160, too.
> 
> I wouldn't recommend it personally, but it is there.

-- 
Patrick Cole <z...@wwwires.com>
Senior Network Specialist
World Without Wires
PO Box 869. Palm Beach, QLD, 4221
Ph:  0410 626 630

Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal

[Patrick W. Gilmore]

On Mar 29, 2017, at 6:48 AM, Mike Hammett <na...@ics-il.net> wrote:
> 
> ISPs lying? Sounds like something for the courts, not capitol hill. 

You can’t sue someone because they do something you do not like. Well, you can, 
but you won’t win.

I guess you could ask for the providers to put it in their terms of service so 
you have something actionable to sue on. Now see my previous post. I tell my 
provider “put in a clause that says you won’t sell my data”. They reply “no”. 
And I do … what exactly?

. . . . . . . . .

Not sure we will get closure here. Some people think ISPs should be allowed to 
see data. Others do not. I am in the latter camp. The law is on the desk of 
POTUS which will do exactly what I do not want. My guess is he will sign it. 

Posting to NANOG will not change that. Shall we agree to disagree and move on?

-- 
TTFN,
patrick

Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal

[Patrick W. Gilmore]

Mike:

I know Mr. Glass thinks of me as a not knowledgeable network professional, but 
I hope you know I’ve been doing “ISP stuff” for a couple decades. I know how to 
work the system. There really are not any other broadband providers in my area. 
Hell, LTE doesn’t even work well in my house, and I am less than a dozen miles 
from the center of Boston.

But more importantly, even if there were a second provider, how do you expect 
Joe & Mary User to find that provider if I cannot? (Not trying to be arrogant, 
just saying I am more experience in this field than the average consumer.)

Broadband competition in the US is a myth, at least for most people. At best, 
competition is the exception, not the rule. At worst, it’s a thinly veiled 
monopoly. Hell, they brag about it being a duopoly where they can, as if that’s 
a great thing. Comcast’s chairman brags that Time Warner & Comcast do not 
compete in any cities.

-- 
TTFN,
patrick

> On Mar 29, 2017, at 6:35 AM, Mike Hammett <na...@ics-il.net> wrote:
> 
> Are there really no others or are the ones that are there just marketing 
> themselves poorly? Any nearby you could convince to expand? 
> 
> Over my WISP's coverage, I have at least 13 WISP competitors, 7 broadband 
> wireline and nearly that many enterprise fiber. I admit that may be 
> exceptional. 
> 
> 
> 
> 
> - 
> Mike Hammett 
> Intelligent Computing Solutions 
> 
> Midwest Internet Exchange 
> 
> The Brothers WISP 
> 
> - Original Message -
> 
> From: "Patrick W. Gilmore" <patr...@ianai.net> 
> To: "NANOG list" <nanog@nanog.org> 
> Sent: Tuesday, March 28, 2017 9:25:54 PM 
> Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers 
> opposed to FCC privacy repeal 
> 
> Thanks, I was a bit confused why you said it, which is apparently because I 
> was confused. :-) 
> 
> I agree we need to do a better job educating users why this is important. 
> 
> And just so my opinion is clear, if there were a true market, I would not 
> mind ISPs who did this (with proper notice). Unfortunately, over half of all 
> households in the US have one or fewer choices for broadband providers. I am 
> one of them. What do I do if my ISP wants to collect my data? VPN everything? 
> 
> -- 
> TTFN, 
> patrick 
> 
>> On Mar 28, 2017, at 10:18 PM, Mike Hammett <na...@ics-il.net> wrote: 
>> 
>> It was more a plea to educate the list on why this matters vs. doom and 
>> gloom with a little more gloom and a little less Carmack. Instead I got more 
>> of the sky is falling. 
>> 
>> Note that I don't intend to ever do this at my ISP, nor my IX. 
>> 
>> 
>> 
>> - 
>> Mike Hammett 
>> Intelligent Computing Solutions <http://www.ics-il.com/> 
>> <https://www.facebook.com/ICSIL> 
>> <https://plus.google.com/+IntelligentComputingSolutionsDeKalb> 
>> <https://www.linkedin.com/company/intelligent-computing-solutions> 
>> <https://twitter.com/ICSIL> 
>> Midwest Internet Exchange <http://www.midwest-ix.com/> 
>> <https://www.facebook.com/mdwestix> 
>> <https://www.linkedin.com/company/midwest-internet-exchange> 
>> <https://twitter.com/mdwestix> 
>> The Brothers WISP <http://www.thebrotherswisp.com/> 
>> <https://www.facebook.com/thebrotherswisp> 
>> <https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg> 
>> From: "Patrick W. Gilmore" <patr...@ianai.net <mailto:patr...@ianai.net>> 
>> To: "NANOG list" <nanog@nanog.org <mailto:nanog@nanog.org>> 
>> Sent: Tuesday, March 28, 2017 9:12:15 PM 
>> Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers 
>> opposed to FCC privacy repeal 
>> 
>> Mike: 
>> 
>> My guess is you do not. 
>> 
>> Which is -precisely- why the users (proletariat?) need to find a way to stop 
>> you. Hence laws & regulations. 
>> 
>> Later in this thread you said “we are done here”. Would that you were so 
>> lucky. 
>> 
>> -- 
>> TTFN, 
>> patrick 
>> 
>>> On Mar 28, 2017, at 5:58 PM, Mike Hammett <na...@ics-il.net 
>>> <mailto:na...@ics-il.net>> wrote: 
>>> 
>>> Why am I supposed to care? 
>>> 
>>> 
>>> 
>>> 
>>> - 
>>> Mike Hammett 
>>> Intelligent Computing Solutions 
>>> 
>>> Midwest Internet Exchange 
>>> 
>>> The Brothers WISP 
>>> 
>>> - Original Message - 
>>> 
>>> From: "Rich Kulawiec"

Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal

[Patrick W. Gilmore]

Thanks, I was a bit confused why you said it, which is apparently because I was 
confused. :-)

I agree we need to do a better job educating users why this is important.

And just so my opinion is clear, if there were a true market, I would not mind 
ISPs who did this (with proper notice). Unfortunately, over half of all 
households in the US have one or fewer choices for broadband providers. I am 
one of them. What do I do if my ISP wants to collect my data? VPN everything?

-- 
TTFN,
patrick

> On Mar 28, 2017, at 10:18 PM, Mike Hammett <na...@ics-il.net> wrote:
> 
> It was more a plea to educate the list on why this matters vs. doom and gloom 
> with a little more gloom and a little less Carmack. Instead I got more of the 
> sky is falling.
> 
> Note that I don't intend to ever do this at my ISP, nor my IX.
> 
> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions <http://www.ics-il.com/>
>  <https://www.facebook.com/ICSIL> 
> <https://plus.google.com/+IntelligentComputingSolutionsDeKalb> 
> <https://www.linkedin.com/company/intelligent-computing-solutions> 
> <https://twitter.com/ICSIL>
> Midwest Internet Exchange <http://www.midwest-ix.com/>
>  <https://www.facebook.com/mdwestix> 
> <https://www.linkedin.com/company/midwest-internet-exchange> 
> <https://twitter.com/mdwestix>
> The Brothers WISP <http://www.thebrotherswisp.com/>
>  <https://www.facebook.com/thebrotherswisp> 
> <https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg>
> From: "Patrick W. Gilmore" <patr...@ianai.net <mailto:patr...@ianai.net>>
> To: "NANOG list" <nanog@nanog.org <mailto:nanog@nanog.org>>
> Sent: Tuesday, March 28, 2017 9:12:15 PM
> Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers 
> opposed to FCC privacy repeal
> 
> Mike:
> 
> My guess is you do not.
> 
> Which is -precisely- why the users (proletariat?) need to find a way to stop 
> you. Hence laws & regulations.
> 
> Later in this thread you said “we are done here”. Would that you were so 
> lucky.
> 
> -- 
> TTFN,
> patrick
> 
> > On Mar 28, 2017, at 5:58 PM, Mike Hammett <na...@ics-il.net 
> > <mailto:na...@ics-il.net>> wrote:
> > 
> > Why am I supposed to care? 
> > 
> > 
> > 
> > 
> > - 
> > Mike Hammett 
> > Intelligent Computing Solutions 
> > 
> > Midwest Internet Exchange 
> > 
> > The Brothers WISP 
> > 
> > - Original Message -
> > 
> > From: "Rich Kulawiec" <r...@gsp.org <mailto:r...@gsp.org>> 
> > To: nanog@nanog.org <mailto:nanog@nanog.org> 
> > Sent: Tuesday, March 28, 2017 4:45:25 PM 
> > Subject: Re: EFF Call for sign-ons: ISPs, networking companies and 
> > engineers opposed to FCC privacy repeal 
> > 
> > On Tue, Mar 28, 2017 at 06:45:04PM +, Mel Beckman wrote: 
> >> The claim oft presented by people favoring this customer abuse is that 
> >> the sold data is anonymous. But it's been well-established that very 
> >> simple data aggregation techniques can develop signatures that reveal 
> >> the identity of people in anonymized data. 
> > 
> > This needs to be repeated loudly and often at every possible opportunity. 
> > I've spent much of the past decade studying this issue and the most 
> > succinct 
> > way I can put it is that however good you (generic "you") think 
> > de-anonymization techniques are, you're wrong: they're way better than 
> > that. 
> > Billions, and I am not exaggerating even a little bit, have been spent 
> > on this problem, and they've been spent by smart people with essentially 
> > unlimited computational resources. And whaddaya know, they've succeeded. 
> > 
> > So if someone presents you a data corpus and says "this data is 
> > anonymized", 
> > the default response should be to mock them, because there is a very high 
> > probability they're either (a) lying or (b) wrong. 
> > 
> > Incidentally, I'm also a signatory of the EFF document, since of course 
> > with nearly 40 years in the field I'm a mere clueless newbie and despite 
> > ripping them a new one about once every other month, I'm clearly a tool 
> > of Google. 
> > 
> > ---rsk 

Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal

[Patrick W. Gilmore]

Mike:

My guess is you do not.

Which is -precisely- why the users (proletariat?) need to find a way to stop 
you. Hence laws & regulations.

Later in this thread you said “we are done here”. Would that you were so lucky.

-- 
TTFN,
patrick

> On Mar 28, 2017, at 5:58 PM, Mike Hammett <na...@ics-il.net> wrote:
> 
> Why am I supposed to care? 
> 
> 
> 
> 
> - 
> Mike Hammett 
> Intelligent Computing Solutions 
> 
> Midwest Internet Exchange 
> 
> The Brothers WISP 
> 
> - Original Message -
> 
> From: "Rich Kulawiec" <r...@gsp.org> 
> To: nanog@nanog.org 
> Sent: Tuesday, March 28, 2017 4:45:25 PM 
> Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers 
> opposed to FCC privacy repeal 
> 
> On Tue, Mar 28, 2017 at 06:45:04PM +, Mel Beckman wrote: 
>> The claim oft presented by people favoring this customer abuse is that 
>> the sold data is anonymous. But it's been well-established that very 
>> simple data aggregation techniques can develop signatures that reveal 
>> the identity of people in anonymized data. 
> 
> This needs to be repeated loudly and often at every possible opportunity. 
> I've spent much of the past decade studying this issue and the most succinct 
> way I can put it is that however good you (generic "you") think 
> de-anonymization techniques are, you're wrong: they're way better than that. 
> Billions, and I am not exaggerating even a little bit, have been spent 
> on this problem, and they've been spent by smart people with essentially 
> unlimited computational resources. And whaddaya know, they've succeeded. 
> 
> So if someone presents you a data corpus and says "this data is anonymized", 
> the default response should be to mock them, because there is a very high 
> probability they're either (a) lying or (b) wrong. 
> 
> Incidentally, I'm also a signatory of the EFF document, since of course 
> with nearly 40 years in the field I'm a mere clueless newbie and despite 
> ripping them a new one about once every other month, I'm clearly a tool 
> of Google. 
> 
> ---rsk 

Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal

[Patrick W. Gilmore]

Having worked networks with massive bandwidth, networks with a single T1 (don’t 
ask, just Google what a T1 is, er, was), and now being somewhere in the middle, 
I agree that the large guys sometimes forget the little guys exist. However, I 
think the change in privacy being proposed hurts -all- users, and 
disproportionately helps the large guys.

A tiny ISP with < 1 Gbps upstream does not have enough user data to sell or 
otherwise “monetize”, while the top 5-10 ISPs have a ready and willing market 
for their users’ data.

Which is why this is so strange. Mr. Glass’ ISP isn’t even a nat on the ass of 
national broadband ISPs. Not an indictment, like I said, I’ve run tiny networks 
myself. However, this change does not help ISPs in his position. Yet he is 
claiming the EFF is fighting for the big guy by opposing this change.

Color me confused. But then again, I am a not knowledgeable network 
professional, so I am probably just confused.

-- 
TTFN,
patrick

> On Mar 28, 2017, at 8:33 AM, Mike Hammett <na...@ics-il.net> wrote:
> 
> Many organizations clamor the FCC for regulation because they hate something 
> about the top 10, 20, etc. ISPs. There is certainly something to hate about 
> them, but almost every time, the baby gets thrown out with the bath water and 
> little ISPs are harmed along the way. Extremes on both sides are what get 
> attention, meanwhile nothing constructive for little ISPs gets done. The 
> policy community forgets them. 
> 
> That same sort of forget about the little guys happens in technical 
> discussions in NANOG as well. Most ISPs and most web hosts have less than 1G 
> of upstream and likely from a single provider. The technical community 
> forgets them. 
> 
> 
> 
> 
> - 
> Mike Hammett 
> Intelligent Computing Solutions 
> 
> Midwest Internet Exchange 
> 
> The Brothers WISP 
> 
> - Original Message -
> 
> From: "Patrick W. Gilmore" <patr...@ianai.net> 
> To: "NANOG list" <nanog@nanog.org> 
> Sent: Monday, March 27, 2017 6:22:27 PM 
> Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers 
> opposed to FCC privacy repeal 
> 
> I am somehow please that Mr. Glass does not find me a “knowledgeable network 
> professional”. It feels like a badge of honor. Any other “not” knowledgeable 
> network professionals want to come forward and accept this badge? 
> 
> Personally, I find the FCC’s current rules to be sub-optimal. But saying a 
> gov’t regulation is sub-optimal is like saying water is wet. The question is 
> not whether the regulation could be improved. It is whether the proposed 
> changes are an improvement. 
> 
> To be 1% clear: I prefer the current privacy regime over the new one 
> being proposed. 
> 
> Oh, and I do not believe the EFF is just a shill for Google. But then, I’m 
> just a not knowledgeable network professional, so what do I know? 
> 
> -- 
> TTFN, 
> patrick 
> 
>> On Mar 27, 2017, at 7:13 PM, Brett Glass <na...@brettglass.com> wrote: 
>> 
>> All: 
>> 
>> It's worth noting that most of EFF's list consists of individuals and/or 
>> politically connected organizations, not actual ISPs. This is for good 
>> reason. EFF was founded with the intention of creating a civil rights 
>> organization but has morphed into a captive corporate lobbying shop for 
>> Google, to which several of its board members have close financial ties. EFF 
>> opposes the interests of hard working ISPs and routinely denigrates them and 
>> attempts to foster promotes hatred of them. It also promotes and lobbies for 
>> regulations which advantage Google and disadvantage ISPs -- including the 
>> so-called "broadband privacy" regulations, which heavily burden ISPs while 
>> exempting Google from all oversight. 
>> 
>> No knowledgeable network professional or ISP would support the current FCC 
>> rules. Both they AND the FCC's illegal Title II classification of ISPs must 
>> be rolled back, restoring the FTC's ability to apply uniform and apolitical 
>> privacy standards to all of the players in the Internet ecosystem. The first 
>> step is to support S.J. Res 34/H.J. Res 86, the Congressional resolution 
>> which would revoke the current FCC regulations that were written and paid 
>> for by Google and its lobbyists. So, DO contact your legislators... but do 
>> so in support of the resolutions that will repeal the regulations. It is 
>> vital to the future of the Internet. 
>> 
>> --Brett Glass, Owner and Founder, LARIAT.NET 
>> 
>> At 05:05 PM 3/26/2017, Peter Eckersley wrote: 
>> 
>>> Dear network operators, 
>>> 
>>> I'm sure this

Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal

[Patrick W. Gilmore]

I am somehow please that Mr. Glass does not find me a “knowledgeable network 
professional”. It feels like a badge of honor. Any other “not” knowledgeable 
network professionals want to come forward and accept this badge?

Personally, I find the FCC’s current rules to be sub-optimal. But saying a 
gov’t regulation is sub-optimal is like saying water is wet. The question is 
not whether the regulation could be improved. It is whether the proposed 
changes are an improvement.

To be 1% clear: I prefer the current privacy regime over the new one being 
proposed.

Oh, and I do not believe the EFF is just a shill for Google. But then, I’m just 
a not knowledgeable network professional, so what do I know?

-- 
TTFN,
patrick

> On Mar 27, 2017, at 7:13 PM, Brett Glass <na...@brettglass.com> wrote:
> 
> All:
> 
> It's worth noting that most of EFF's list consists of individuals and/or 
> politically connected organizations, not actual ISPs. This is for good 
> reason. EFF was founded with the intention of creating a civil rights 
> organization but has morphed into a captive corporate lobbying shop for 
> Google, to which several of its board members have close financial ties. EFF 
> opposes the interests of hard working ISPs and routinely denigrates them and 
> attempts to foster promotes hatred of them. It also promotes and lobbies for 
> regulations which advantage Google and disadvantage ISPs -- including the 
> so-called "broadband privacy" regulations, which heavily burden ISPs while 
> exempting Google from all oversight.
> 
> No knowledgeable network professional or ISP would support the current FCC 
> rules. Both they AND the FCC's illegal Title II classification of ISPs must 
> be rolled back, restoring the FTC's ability to apply uniform and apolitical 
> privacy standards to all of the players in the Internet ecosystem. The first 
> step is to support S.J. Res 34/H.J. Res 86, the Congressional resolution 
> which would revoke the current FCC regulations that were written and paid for 
> by Google and its lobbyists. So, DO contact  your legislators... but do so in 
> support of the resolutions that will repeal the regulations. It is vital to 
> the future of the Internet.
> 
> --Brett Glass, Owner and Founder, LARIAT.NET
> 
> At 05:05 PM 3/26/2017, Peter Eckersley wrote:
> 
>> Dear network operators,
>> 
>> I'm sure this is a controversial topic in the NANOG community, but EFF and a
>> number of ISPs and networking companies are writing to Congress opposing the
>> repeal of the FCC's broadband privacy rules, which require explicit opt-in
>> consent before ISPs use or sell sensitive, non-anonymized data (including
>> non-anonymized locations and browsing histories).
>> 
>> If you or your employer would like to sign on to such a letter, please reply
>> off-list by midday Monday with your name, and a one-sentence description of
>> your affiliation and/or major career accomplishments.

Re: Conference Videos

[Patrick W. Gilmore]

On Mar 13, 2017, at 6:06 PM, Steve Feldman <feld...@twincreeks.net> wrote:
> On Mar 13, 2017, at 2:52 PM, Mike Hammett <na...@ics-il.net> wrote:
>> 
>> Another organization I'm in has a hard policy of no recordings of any 
>> sessions at their conferences. They think that recordings of content (even 
>> vendor-sponsored, vendor-specific sessions with vendor consent) would have a 
>> catastrophic effect on conference attendance. 
>> 
>> NANOG doesn't seem to have that issue. Any background on the process to get 
>> there? Any regrets? 
>> 
> 
> Many attendees also find value in the parts of the conference that aren't 
> recorded, like hallway conversations, informal meetings, and even social 
> events.
> 
> Keeping and maintaining the archive of slides and video recordings is an 
> essential part of NANOG's educational mission, which was key to obtaining and 
> maintaining the IRS 401(c)(3) nonprofit status.
> 
> So at least for the time I was on the Board, not only were there no regrets, 
> but we worked hard to maintain and enhance the video experience.



Speakers are informed they are going to be recorded. If they have sensitive 
information, they can choose a track and ask it not be recorded. NANOG has done 
this in the past, but you should talk to the Program Committee if you are 
interested in this.

-- 
TTFN,
patrick

Re: google ipv6 routes via cogent

[Patrick W. Gilmore]

On Mar 3, 2017, at 9:05 PM, Job Snijders <j...@instituut.net> wrote:
> On Fri, Mar 03, 2017 at 09:42:04AM -0500, Patrick W. Gilmore wrote:
>> On Mar 3, 2017, at 7:00 AM, Nick Hilliard <n...@foobar.org> wrote:
>>> Niels Bakker wrote:
>>>> As I explained in the rest of my email that you conveniently didn't
>>>> quote, it's so that you can selectively import routes from all your
>>>> providers in situations where your router cannot handle a full table.
>>> 
>>> it can also break horribly in situations where the provider is providing
>>> "transit" but doesn't provide full transit.
>>> 
>>> OTOH, if you are single-homed, it is highly advisable to accept a
>>> default, the reason being that most transit providers provide bgp
>>> communities with "don't advertise to customers" semantics.  So if you're
>>> single-homed and use a full dfz feed without default route, you will not
>>> have full connectivity to all the routes available from the transit
>>> provider.
> 
> Correct.
> 
>> If you are single-homed, there is no need for BGP at all.
> 
> That is very strongly worded, and in plenty of cases a false assertion.
> 
>> And injecting your ASN into the table is probably not terribly useful
>> to everyone else’s FIB.
> 
> ASNs don't have anything to do with FIB.
> 
>> There are, of course, corner cases. But in general, single-homed
>> people shouldn’t be using BGP.
> 
> There are numerous reasons to use BGP when single-homed:
> 
>- as preparation to multi-home in the (near) future
>- ability to quickly change providers
>- to use BGP based blackholing features
>- to save time on provisioning work (adding new prefixes becomes a
>  matter of just announcing and updating IRR/RPKI).
>- loadbalanacing / loadsharing across multiple links
>- ability to use bgp communities for traffic engineering
> 
> In other words, if you have your own IP space, I'd recommend to get your
> own ASN and use BGP.

First, I said specifically there are corner cases. Everything you say above is 
a corner case. The sum of everyone in need of the above is to the right of the 
decimal compared to all single homed networks. Limiting it to “it you have your 
own IP space” makes the set even smaller.

You are also reaching here. Preparation for multi-homing in the near future is 
just multi-homing. Adding prefixes is a very occasional thing, and in some 
cases is actually not easier with BGP. (Ever worked with some provider’s IRR 
implementation?) Etc.

End of day, if you have your own space and only allow aggregates into the DFZ, 
even as a stub behind someone else, it doesn’t really save RIB slots compared 
to having the upstream announce it for you. My problem is making the exceptions 
sound normal. They are not, and we should not treat them as if they are. Else 
we will end up with people wanting to do it who do not understand what they are 
doing, polluting the table, etc.

I stand by my statement. Single Homed Networks Should Not Use BGP. It is a good 
general rule. There are exceptions, but the exceptions are rare and should be 
approached with caution & clue.

-- 
TTFN,
patrick

Re: google ipv6 routes via cogent

[Patrick W. Gilmore]

On Mar 3, 2017, at 7:00 AM, Nick Hilliard <n...@foobar.org> wrote:
> 
> Niels Bakker wrote:
>> As I explained in the rest of my email that you conveniently didn't
>> quote, it's so that you can selectively import routes from all your
>> providers in situations where your router cannot handle a full table.
> 
> it can also break horribly in situations where the provider is providing
> "transit" but doesn't provide full transit.
> 
> OTOH, if you are single-homed, it is highly advisable to accept a
> default, the reason being that most transit providers provide bgp
> communities with "don't advertise to customers" semantics.  So if you're
> single-homed and use a full dfz feed without default route, you will not
> have full connectivity to all the routes available from the transit
> provider.

If you are single-homed, there is no need for BGP at all. And injecting your 
ASN into the table is probably not terribly useful to everyone else’s FIB.

There are, of course, corner cases. But in general, single-homed people 
shouldn’t be using BGP.

-- 
TTFN,
patrick

Re: SHA1 collisions proven possisble

[Patrick W. Gilmore]

Composed on a virtual keyboard, please forgive typos. 

On Feb 26, 2017, at 21:16, Matt Palmer <mpal...@hezmatt.org> wrote:
>> On Sun, Feb 26, 2017 at 05:41:47PM -0600, Brett Frankenberger wrote:
>>> On Sun, Feb 26, 2017 at 12:18:48PM -0500, Patrick W. Gilmore wrote:
>>> I repeat something I've said a couple times in this thread: If I can
>>> somehow create two docs with the same hash, and somehow con someone
>>> into using one of them, chances are there are bigger problems than a
>>> SHA1 hash collision.
>>> 
>>> If you assume I could somehow get Verisign to use a cert I created to
>>> match another cert with the same hash, why in the hell would that
>>> matter?  I HAVE THE ONE VERISIGN IS USING.  Game over.
>>> 
>>> Valdis came up with a possible use of such documents. While I do not
>>> think there is zero utility in those instances, they are pretty small
>>> vectors compared to, say, having a root cert at a major CA.
>> 
>> I want a google.com cert.  I ask a CA to sign my fake google.com
>> certificate.  They decline, because I can't prove I control google.com.
> 
> Even better: I want a CA cert.  I convince a CA to issue me a regular,
> end-entity cert for `example.com` (which I control) in such a way that I can
> generate another cert with the same SHA1 hash, but which has `CA:TRUE` for
> the Basic Constraints extension.
> 
> Wham!  I can now generate certs for *EVERYONE*.  At least until someone
> notices and takes away my shiny new toy...

Since I have said this somewhere on the order of half a dozen times, I will 
assume I am missing something obvious and all of you are doing it right. 

So let me ask you: The attack creates two docs. You do not know the hash before 
the attack starts. You cannot take an existing file with a known hash and 
create a second file which matches the known hash. You start with nothing, run 
the "attack", and get two NEW docs that have the same hash. A hash which is 
brand new. 

Now, please explain how you take a cert with one hash and somehow use this 
attack, which creates two new docs with a new hash, to do, well, anything?

In the example above, the CA knows the SHA-1 hash of the cert it issued. (We 
are assuming there is a CA which still does SHA-1.) How do you get that CA to 
believe the two OTHER certs with DIFFERENT hashes you have to create so you can 
have two docs with the same hash?

-- 
TTFN,
patrick