Re: [External] Fiber aggregators and such

[Ross Tajvar]

I saw willingness to share large-scale KMZs drop significantly after that
incident. It definitely had an impact.

On Mon, Mar 4, 2024 at 1:55 PM Hunter Fuller via NANOG 
wrote:

> On Mon, Mar 4, 2024 at 12:37 PM Tom Beecher  wrote:
> >>  I think there is
> >> a very careful attitude around making sure not just anyone can get
> >> this information, especially after the Nashville bombing on Christmas
> >> Day 2020.
> >
> > Keeping fiber location info close to the vest is nothing new. I'm not
> now sure why/how you feel like this connects to the Nashville incident.
>
> I wouldn't say it's new, but in this area (TN Valley), things
> definitely tightened up even more, in the wake of that incident.
> Probably due to proximity to Nashville. I can't speak to any other
> regions of course.
>

Re: Dark Fiber in DC Metro

[Ross Tajvar]

DC is different from VA.

E.g. Astound has a lot of fiber in DC, but not in VA. SummitIG has a lot of
fiber between datacenters (i.e. not in DC), but not to non-datacenter
premises.

Can you be more specific about what you're looking for?

On Mon, Mar 4, 2024 at 7:31 AM Theo Voss  wrote:

> Hi all,
>
> does anyone has a recommendation for a Dark Fiber provider in the DC Metro
> (Ashburn/Reston) area? Preferably an easy to work with one. :-)
>
> Appreciate any hints, thanks!
>
> Best regards,
> Theo Voss

Re: Meta outage

[Ross Tajvar]

That's from 2010. You can see if you look at the non-mobile version of the
page (requires login though):
https://www.facebook.com/notes/10158791436142200/
[image: image.png]

On Tue, Mar 5, 2024 at 1:32 PM Jorge Amodio  wrote:

>
> https://m.facebook.com/nt/screen/?params=%7B%22note_id%22%3A10158791436142200%7D=%2Fnotes%2Fnote%2F
>
> - Jorge (mobile)
>
>
> On Mar 5, 2024, at 10:25, Kain, Becki (.) via NANOG 
> wrote:
>
> 
>
> Does meta keep a board somewhere to tell the world it’s down?
>
>
>
> *From:* NANOG  *On Behalf Of *Jay
> Ashworth
> *Sent:* Tuesday, March 05, 2024 11:06 AM
> *To:* nanog@nanog.org
> *Subject:* Meta outage
>
>
>
> WARNING: This message originated outside of Ford Motor Company. Use
> caution when opening attachments, clicking links, or responding.
>
>
>
> It's making the general press this hour so of course you already know
> about it but my question is this: who peers with meta and have you seen BGP
> sessions drop or the like? Do you operate meta CDN nodes in your network?
> Are they screaming for help?
>
> This doesn't sound like it's a network layer problem but I'm curious.
>
> Cheers,
> -- jra
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
>

CPE/NID options

[Ross Tajvar]

I'm evaluating CPEs for one of my clients, a regional ISP. Currently, we're
terminating the customer's service (L3) on our upstream equipment and
extending it over our own fiber to the customer's premise, where it lands
in a Juniper EX2200 or EX2300.

At a previous job, I used Accedian's ANTs on the customer prem side. I like
the ANT because it has a small footprint with only 2 ports, it's passively
cooled, it's very simple to operate, it's controlled centrally, etc.
Unfortunately, when I reached out to Accedian, they insisted that the
controller (which is required) started at $30k, which is a non-starter for
us.

I'm not aware of any other products like this. Does anyone have a
recommendation for a simple L2* device to deploy to customer premises? Not
necessarily the exact same thing, but something similarly-featured would be
ideal.

*I'm not sure if the ANT is exactly "layer 2", but I don't know what else
to call it.

Re: 1299 capacity constraints

[Ross Tajvar]

Someone else made this joke via direct email. Old minds think alike?

On Sun, Jul 16, 2023 at 7:39 PM Matthew Petach 
wrote:

>
>
> On Fri, Jul 14, 2023, 15:27 Ross Tajvar  wrote:
>
>> It extremely depends on who you're trying to reach and from what
>> location. We've seen lots of T1s have congested peering lately.
>>
>
> Whoa.
>
> I thought I was the only one old-school enough to still be using a T1 for
> connectivity.  Are people seriously actually trying to use T1s for peering
> in this day and age?  ^_^;
>
> Matt
>
>
>

Re: 1299 capacity constraints

[Ross Tajvar]

It extremely depends on who you're trying to reach and from what location.
We've seen lots of T1s have congested peering lately. Unfortunately these
days, having uncongested path requires paying a lot of attention and
distributing your traffic yourself rather than simply handing it off to
your transit providers.

On Fri, Jul 14, 2023, 7:57 AM Drew Weaver  wrote:

> Has anyone else been having near constant issues with traffic transiting
> AS 1299 being lost due to their links being oversubscribed?
>
>
>
> Off-list is fine, I am just trying to get a sense of what is going on
> there.
>
>
>
> Thanks,
>
> -Drew
>
>
>

Re: Lima, OH Spectrum/Charter Severe Node/Hop Latency Issues

[Ross Tajvar]

For those who haven't seen it (i.e. Austin), here is "the guide" on how to
troubleshoot correctly with traceroute:
https://archive.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_N47_Sun.pdf

ICMP is deprioritized by any normal router. Non-cascading loss does not
indicate a problem of any kind. The NOC doesn't care because nothing is
wrong, and the OSP team definitely doesn't care because ICMP is several
layers above OSP and is therefore not their problem.

On Tue, Feb 7, 2023 at 5:11 PM Kevin Shymkiw  wrote:

> ICMP response time from a router/device is not a great way to judge if
> there is an issue or not.  The devices generally have control plane
> policing and responding to ICMP is not prioritized at all.
>
> I would suggest your engineer setup something on their end of the
> connection that you can ping, and start there.
>
> Leverage something like smoke ping to something on their LAN, or even the
> public IP on their RG/Modem.
>
> Kevin
>
> On Tue, Feb 7, 2023 at 15:01 Austin Ayers via NANOG 
> wrote:
>
>> Hello all,
>>
>> One of my NetOps engineers resides in Lima, Ohio and they are receiving
>> terrible bufferbloat, packet loss, and random disconnects.
>>
>> I have been pinging 24.33.160.213 (Lima, OH Spectrum/Chart Node) and it's
>> rejecting a ton of packets. This has been going on for weeks.
>>
>> Node having problems: lag-1.limaohid01h.netops.charter.com
>>
>> NOC seems like they don't care, same with OSP in the field.
>>
>> There is no reason why this hop (#13) should have up to 613ms ping times.
>>
>> Thank you,
>> Austin
>>
>>
>>

Re: Verizon Wireless NRB group

[Ross Tajvar]

Not sure if you have this already, but their phone number is +1
866-899-8998.

On Tue, May 10, 2022 at 10:41 AM Mark Stevens  wrote:

> Verizon Wireless had a serious 4G/LTE issue affecting the Thingspace
> product that cause a complete outage for many of our customers.
> It would be greatly appreciated if someone from the Verizon NRB (Network
> Repair) group would connect with me offline the routing and filtering
> issues we saw.
>
>
> Thanks
>
> Mark
>

Re: Could people with experience with ARIN's IRR API contact me off-list?

[Ross Tajvar]

I don't have anything for you, but I'm curious what IPAM you're using and
what difficulties you're having. I'm looking to do something similar.

On Wed, Apr 27, 2022 at 12:27 AM Dan Mahoney (Gushi) 
wrote:

> All,
>
> Dayjob uses RADB mainly but would like for authority purposes to put some
> things in ARIN.
>
> I've had an ARIN help desk ticket in for a couple days, and would like to
> move to letting our IPAM files be the source of truth and push everything
> in via the API, but I'm finding a few things about the API just obtuse.
>
> I could post that laundry list here, but I'd prefer to get confirmations
> from people who've written tools against it what tools you found useful,
> and if the broken things I'm seeing are actually as broken as I think they
> are.
>
> ARIN people who implemented this, I'd love to hear from you as well.
>
> Best,
>
> -Dan
>
> --
>
>

Fwd: Fw: HOST IRR Retirement

[Ross Tajvar]

I tried sending the below message from my work account, but it's not a
nanog subscriber, so the email was rejected. If anyone doubts the
authenticity, feel free to reach out to me at rtaj...@365datacenters.com.


--
*From:* Ross Tajvar
*Sent:* Monday, April 11, 2022 3:53 PM
*To:* nanog@nanog.org 
*Subject:* HOST IRR Retirement

Hi all,

We (365 Datacenters) inherited the HOST IRR. We have removed all stale
objects from it, and moved all valid objects to other IRRs. We will
eventually (hopefully soon) turn it off altogether. Please, if you are
mirroring it, stop doing that. If you maintain documentation that lists
IRRs, please update it to reflect that HOST is no longer in use.

Thanks!

P.S. If anyone thinks I should also announce this somewhere else, please
let me know.

*Ross Tajvar*

Network Engineer

Office: (571)-341-8899

Support: (866)-365-6246

Re: Authoritative Resources for Public DNS Pinging

[Ross Tajvar]

Meraki finally allowed an operator to stop this a few years ago, but it's
still the default.

On Tue, Feb 8, 2022 at 6:34 PM Mike Lewinski via NANOG 
wrote:

> Anyone swinging a clue-by-four it going to hit Meraki real hard.
>
>
> https://community.meraki.com/t5/Switching/Switch-Constantly-Pings-8-8-8-8/m-p/31491
>

Fiber contractor in Washington state

[Ross Tajvar]

Hi all,

I'm looking for a fiber contractor to trench some fiber on private property
and then splice it inside. The work will be in Washington state, north of
Spokane. Does anyone have recommendations? On- and off-list welcome.

Thanks,
Ross

Re: BGP communities, was: Re: Facebook post-mortems... - Update!

[Ross Tajvar]

There are also a bunch at http://bgp.community (linked to the source where
possible instead of keeping a stale copy).

On Tue, Oct 5, 2021, 1:17 PM Jay Hennigan  wrote:

> On 10/5/21 09:49, Warren Kumari wrote:
>
> > Can someone explain to me, preferably in baby words, why so many
> > providers view information like https://as37100.net/?bgp
> >  as secret/proprietary?
> > I've interacted with numerous providers who require an NDA or
> > pinky-swear to get a list of their communities -- is this really just 1:
> > security through obscurity, 2: an artifact of the culture of not
> > sharing, 3: an attempt to seem cool by making you jump through hoops to
> > prove your worthiness, 4: some weird 'mah competitors won't be able to
> > figure out my secret sauce without knowing that 17 means Asia, or 5:
> > something else?
>
> Not sure the rationale of leeping them secret, but at least one
> aggregated source of dozens of them exists and has been around for a
> long time. https://onestep.net/communities/
>
> --
> Jay Hennigan - j...@west.net
> Network Engineering - CCIE #7880
> 503 897-8550 - WB6RDV
>

Re: BGP - Traffic Management

[Ross Tajvar]

Atlantic Metro (now 365 Datacenters) AS29838 allows more specifics on our
backbone. We filter outbound to transit and peering obviously, but we allow
e.g. granular steering if you have more than one port with us.

On Thu, Aug 19, 2021, 1:23 PM Ryan Hamel  wrote:

> Hello,
>
>
>
> Does anyone know of any US carriers that will accept more specific routes
> other than what’s required for the DFZ, like “le 31” or “upto /31” (junos
> speak) ? I know Zayo supports this internally but would like to know of
> other carriers for redundancy.
>
>
>
> I am currently dealing with a network that has per region assigned public
> IP blocks. I would like to see about moving to announcing aggregates to the
> carriers across the MPLS network and redistributing more specifics from
> iBGP to the carriers to get the traffic where it needs to be. In a failover
> situation these more specifics are also visible on an MPLS backbone where
> other transit routers will prepend the AS path upstream based on specific
> communities to prevent anycast routing.
>
>
>
> Thanks,
>
>
>
> Ryan
>

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

[Ross Tajvar]

I, and many others that I know, have successfully listed our networks in
PeeringDB while having no peering. You may just need to try again.

On Wed, Aug 18, 2021, 5:53 PM Sabri Berisha  wrote:

> - On Aug 18, 2021, at 2:21 PM, Patrick W. Gilmore 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
> Received: from mail.cluecentral.net (LHLO mail.cluecentral.net)
>  (195.16.84.32) by 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 (Postfix) with ESMTP id 4CED64001EF
> for ; Fri,  9 Oct 2015 01:47:22 -0700 (PDT)
> Received: from mail.cluecentral.net ([127.0.0.1])
> by localhost (mail.cluecentral.net [127.0.0.1]) (amavisd-new,
> port 10024)
> with ESMTP id 3TLvVaNdjHGA for ;
> Fri,  9 Oct 2015 01:47:21 -0700 (PDT)
> Received: from ubersmith.peeringdb.com (ubersmith.peeringdb.com
> [107.6.74.106])
> by mail.cluecentral.net (Postfix) with ESMTP id C5B164001A9
> for ; Fri,  9 Oct 2015 01:47:01 -0700 (PDT)
> Received: by 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 
> From: supp...@peeringdb.com
> Reply-To: supp...@peeringdb.com
> Subject: Re: [#9192] [PeeringDB] User (sabri) Requesting Access (New
> Company - Cluecentral Inc)
> Message-ID: <1bac170d74e5d3702d3a28b237c87...@ubersmith.peeringdb.com>
>
> Dear PeeringDB user,
>
> Registering with peeringDB and peering negotiations are sort of egg and
> chicken problem. We only want to have networks registered that already
> do have settlement free peering.
>
> After some basic checks it looks like you are only buying transit from
> 6939/Hurricane Electric, but are not connected to any Internet Exchange
> (e.g. AMS-IX/NL-ix) yet.
>
> Having said this, is it acceptable to you to wait until you have your
> 1st settlement free peering setup? If you already have existing peering
> sessions, please provide the following details to support your request for
> peeringdb access:
>
> Your AS number(s)
> Which IXP / facilities you are peering at
> Some of your peering partners (again AS numbers / name)
>
> Please send your answers to supp...@peeringdb.com or reply to this ticket.
>
>
> Best regards,
> PeeringDB admin on Duty
>
>
> PeeringDB Listserv information:
>
> PeeringDB Announce:
> http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-announce
>
> PeeringDB Governance:
> http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-gov
>
> PeeringDB Technical:
> http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-tech
>
> PeeringDB User Discuss:
> http://lists.peeringdb.com/cgi-bin/mailman/listinfo/user-discuss
>
> --
> Florian Hibler 
> PeeringDB Administrator
>

Buying IPs with poor reputation

[Ross Tajvar]

I'm curious if anyone has experience deliberately buying blacklisted
blocks, or blocks that otherwise have poor reputation. Is there a
significant price difference? How do you seek them out? Most of the sellers
I've found seem to focus on blocks with good reputation, or on improving
the reputation of a bad block. But I am interested in purchasing some IPs
for internal services where reputation doesn't really matter.

Thanks,
Ross

Re: Contact data for outlook.com

[Ross Tajvar]

You may also try the mailops list.

On Tue, Mar 9, 2021, 12:55 PM Matthew V  wrote:

> If you haven't done this yet - start with the outlook postmaster
> troubleshooting documentation and open a support ticket with them.
>
> https://sendersupport.olc.protection.outlook.com/pm/troubleshooting.aspx
>
> Matt
>
> On 2021-03-09 7:07 a.m., s...@circlenet.us wrote:
> > You are not alone sir, for reasons as yet unknown outlook.com has
> > recently started blocking my range as well.
> > If I make progress in contacting someone with clue I will pass that
> > information along privately.
> >
> > Sam Moats
> >
> > On 2021-03-08 16:18, Dan Walters via NANOG wrote:
> >> Good afternoon,
> >>
> >> So I'm looking for a contact at Microsoft in particular someone on the
> >> outlook spam protection/prevention team to assist us with a IP block.
> >> I have allready signed up for SNDS and there is no data given .
> >> Please feel free to contact me off the list.
> >>
> >> Best Regards,
> >>
> >> Daniel Walters
>

Charter/spectrum contact (AS20115)

[Ross Tajvar]

Hi, can someone reach out off-list please? We are seeing very high latency
to Spectrum residential users from LAX.

Re: Telstra Hijack

[Ross Tajvar]

Bad prefixes are all gone. This looks resolved from my point of view.

On Tue, Sep 29, 2020 at 5:18 PM Ross Tajvar  wrote:

> I'm still seeing bad prefixes from Cogent, but our other upstreams (NTT,
> GTT, Telia) blocked them.
>
> On Tue, Sep 29, 2020 at 5:09 PM Sadiq Saif  wrote:
>
>> On Tue, 29 Sep 2020, at 16:36, Ross Tajvar wrote:
>> > I'm surprised no one else has mentioned this yet, but Telstra is
>> > hijacking a lot of prefixes:
>> >
>> >
>> https://rpki.cloudflare.com/?view=bgp==1221=Invalid
>> >
>> > Since we don't have RPKI filtering in our network (yet), we are
>> > currently filtering everything with the path ".* 4637 1221$".
>> >
>> > This is of course taking a while...
>>
>> My employer's prefixes were affected, I posted about it on the AusNOG
>> list so I could get some assistance. It has cleared up now but it took
>> about two hours or so.
>>
>> I saw AS paths like this from HE's looking glass:
>> 6461x4, 4637x11, 1221
>>
>> I would love to know what the root cause of the leak was.
>>
>> --
>>   Sadiq Saif
>>
>

Re: Telstra Hijack

[Ross Tajvar]

I'm still seeing bad prefixes from Cogent, but our other upstreams (NTT,
GTT, Telia) blocked them.

On Tue, Sep 29, 2020 at 5:09 PM Sadiq Saif  wrote:

> On Tue, 29 Sep 2020, at 16:36, Ross Tajvar wrote:
> > I'm surprised no one else has mentioned this yet, but Telstra is
> > hijacking a lot of prefixes:
> >
> >
> https://rpki.cloudflare.com/?view=bgp==1221=Invalid
> >
> > Since we don't have RPKI filtering in our network (yet), we are
> > currently filtering everything with the path ".* 4637 1221$".
> >
> > This is of course taking a while...
>
> My employer's prefixes were affected, I posted about it on the AusNOG list
> so I could get some assistance. It has cleared up now but it took about two
> hours or so.
>
> I saw AS paths like this from HE's looking glass:
> 6461x4, 4637x11, 1221
>
> I would love to know what the root cause of the leak was.
>
> --
>   Sadiq Saif
>

Telstra Hijack

[Ross Tajvar]

I'm surprised no one else has mentioned this yet, but Telstra is hijacking
a lot of prefixes:

https://rpki.cloudflare.com/?view=bgp==1221=Invalid

Since we don't have RPKI filtering in our network (yet), we are currently
filtering everything with the path ".* 4637 1221$".

This is of course taking a while...

Re: Does anyone actually like CenturyLink?

[Ross Tajvar]

True, but I was including conversations with colleagues where we generally
*do* discuss carriers we like.

On Mon, Aug 31, 2020 at 9:28 AM Tom Beecher  wrote:

> I've never heard a single positive word about them
>>
>
> There is rarely much in the way of emails/messages sent about things when
> they work well.
>
> On Sun, Aug 30, 2020 at 11:03 AM Ross Tajvar  wrote:
>
>> I've never heard a single positive word about them, and I've had my fair
>> share of issues myself (as an indirect customer). But it seems that lots of
>> people put them in their transit blend. Other than lack of options, why
>> would anyone use them? To me, it just seems like asking for trouble...but
>> maybe I'm missing something?
>>
>

Re: Centurylink having a bad morning?

[Ross Tajvar]

Not being intentional isn't really an excuseOutages are generally not
intentional but we still like to use services that stay up most of the time.

On Sun, Aug 30, 2020 at 11:11 AM Drew Weaver  wrote:

> I’m not defending them but I am sure it isn’t intentional.
>
>
>
> *From:* NANOG  *On Behalf
> Of *Baldur Norddahl
> *Sent:* Sunday, August 30, 2020 9:28 AM
> *To:* nanog@nanog.org
> *Subject:* Re: Centurylink having a bad morning?
>
>
>
> How is that acceptable behaviour? I shall remember never to make a
> contract with these guys until they can prove that they won't advertise my
> prefixes after I pull them. Under any circumstances.
>
>
>
> søn. 30. aug. 2020 15.14 skrev Joseph Jenkins  >:
>
> Finally got through on their support line and spoke to level1. The only
> thing the tech could say was it was an issue with BGP route reflectors and
> it started about 3am(pacific). They were still trying to isolate the issue.
> I've tried failing over my circuits and no go, the traffic just dies as L3
> won't stop advertising my routes.
>
>
>
> On Sun, Aug 30, 2020 at 5:21 AM Drew Weaver via NANOG 
> wrote:
>
> Hello,
>
>
>
> Woke up this morning to a bunch of reports of issues with connectivity had
> to shut down some Level3/CTL connections to get it to return to normal.
>
>
>
> As of right now their support portal won’t load:
> https://www.centurylink.com/business/login/
>
>
>
> Just wondering what others are seeing.
>
>
>
>

Does anyone actually like CenturyLink?

[Ross Tajvar]

I've never heard a single positive word about them, and I've had my fair
share of issues myself (as an indirect customer). But it seems that lots of
people put them in their transit blend. Other than lack of options, why
would anyone use them? To me, it just seems like asking for trouble...but
maybe I'm missing something?

Re: Issue with Noction IRP default setting (Was: BGP route hijack by AS10990)

[Ross Tajvar]

I guess I missed your mention of "guidance rather than regulation", and am
still missing it, unless you're referring to another thread.

If you want to acknowledge a problem with internet governance and bring it
to this mailing list for discussion, that sounds like a good idea. But the
only "problem" I've seen you bring up in this thread is the participation
of young people, and I've yet to hear a reason why that's a bad thing. This
just sounds like gatekeeping to me.

If we want to improve routing security, then rather than making vague
claims about things "catching up with us" with no clear problem statement,
we should be focusing our efforts on basic safeguards like filtering and
RPKI OV. I don't consider that "burying my head in the sand".

On Sun, Aug 2, 2020, 5:24 PM Mark Tinka  wrote:

>
>
> On 2/Aug/20 21:37, Ross Tajvar wrote:
> > Mark,
> >
> > I think trying to implement some kind of license requirement for DFZ
> > participants is a step in the wrong direction and a waste of time and
> > money. How would you even enforce it? If the goal is just to provide a
> > bigger barrier to "kids born after 9/11", why not just increase RIR
> > fees, or add an age requirement for individuals? And anyway, why do we
> > need to increase that barrier? What problem does that actually solve?
> > Are "kids born after 9/11" the ones propagating route leaks? I don't
> > think they are. But the reason for that is not that they're
> > necessarily more skilled operators than "adults born before 9/11" or
> > anyone else - it's that they are being filtered appropriately by the
> > likes of Vultr, etc. Verizon (and other large incumbents) could learn
> > something from them.
> >
> > Let's try to stay away from exclusivity for exclusivity's sake and
> > actually focus on solving the real problems we have.
>
> Like I said before, "guidance" rather than "regulation".
>
> The way the Internet has worked for 4+ decades has been what has made it
> so successful. However, it's starting to catch up with us, so we need to
> figure it out, and not bury our heads in the sand until it hurts me or
> you more directly for either us to care.
>
> Like I also said, I don't quite know how to solve this problem yet. What
> I do know is if we keep having this dance every few months each year, it
> will be 2050 and we'll still be in the same place, only worse.
>
> Before we can find a solution, we have to realize that there is a
> problem. There is enough smarts in the community to find a solution.
> Hopefully before some silly gubbermint (TikTok ban, anyone?) decides for
> us.
>
> Mark.
>
>

Re: Issue with Noction IRP default setting (Was: BGP route hijack by AS10990)

[Ross Tajvar]

Mark,

I think trying to implement some kind of license requirement for DFZ
participants is a step in the wrong direction and a waste of time and
money. How would you even enforce it? If the goal is just to provide a
bigger barrier to "kids born after 9/11", why not just increase RIR fees,
or add an age requirement for individuals? And anyway, why do we need to
increase that barrier? What problem does that actually solve? Are "kids
born after 9/11" the ones propagating route leaks? I don't think they are.
But the reason for that is not that they're necessarily more skilled
operators than "adults born before 9/11" or anyone else - it's that they
are being filtered appropriately by the likes of Vultr, etc. Verizon (and
other large incumbents) could learn something from them.

Let's try to stay away from exclusivity for exclusivity's sake and actually
focus on solving the real problems we have.

On Sun, Aug 2, 2020 at 12:45 PM Mark Tinka  wrote:

>
>
> On 2/Aug/20 01:44, Ryan Hamel wrote:
>
> Matt,
>
> Why are you blaming the ease of use on the vendor, for the operators lack
> of knowledge regarding BGP? That is like blaming a vehicle manufacturer for
> a person pressing the gas pedal in a car and not giving a toss about the
> rules of the road. The base foundation regarding the rules of the road
> mostly apply the same for driving a car, truck, bus, and semi/lorry truck.
> There is no excuse for ignorance just because the user interface is
> different (web browser vs. SSH client).
>
>
> Actually, there is.
>
> One has to actually acquire knowledge about not only driving a car, but
> driving it in public. That knowledge is then validated by a
> gubbermint-sanctioned driver's license test. If you fail, you aren't
> allowed to drive. If you are caught driving without a driver's license, you
> pay the penalty.
>
> There is no requirement for a license in order to run power into a router
> and hook it up to the Internet. This is the problem I have with the current
> state of how we support BGP actors.
>
> Adding a take on this, there are kids born after 9/11, with IP allocations
> and ASNs experimenting in the DFZ right now. If they can make it work, and
> not cause harm to other members in this community, it clearly demonstrates
> a lack of knowledge, or honest human error (which will never go away).
>
>
> We should not be celebrating this.
>
>
>
> Anything that can be used, can be misused. With that said, why shouldn't
> ALL BGP software implementations encourage best practice? They decided RPKI
> validation was a good thing.
>
>
> The larger question is we should find a way to make our industry genuinely
> qualification-based, and not "free for all that decides they want to try it
> out".
>
> I don't yet know how to do that, but we certainly need to start thinking
> more seriously about it. Kids born after 9/11 successfully experimenting on
> a global network is not where the bar ought to be.
>
> Mark.
>

Re: Constant Abuse Reports / Borderline Spamming from RiskIQ

[Ross Tajvar]

 On Wed, Apr 15, 2020 at 8:52 AM Rich Kulawiec  wrote:

> there are
> all kinds of things that can be done to detect problematic customers
> before you sign them up and once they're in place.
>

Hey Rich,

Can you give some examples of the things you mention above? I'm not doing
much in terms of customer filtering and would be interested to hear what
others consider best practice.

-Ross

Re: Chairman Pai Proposes Mandating STIR/SHAKEN To Combat Robocalls

[Ross Tajvar]

What is an "ebony phone"? (Google results for that phrase are mostly porn.)

On Sat, Mar 7, 2020 at 12:55 PM Christopher Morrow 
wrote:

> On Sat, Mar 7, 2020 at 4:10 AM Bryan Holloway  wrote:
> >
> >
> > On 3/7/20 8:03 AM, Christopher Morrow wrote:
> > > On Fri, Mar 6, 2020 at 11:05 PM Brian J. Murrell <
> br...@interlinx.bc.ca> wrote:
> > >
> > >> So, if my telco can bill the callers for those premium calls, they
> > >> surely know who they are, or at least know where they are sending the
> > >> bill and getting payment from.
> > >
> > > You are mistaken, billing is very hard.
> > > Telcos show this regularly.
> > >
> >
> > On the contrary: billing is easy. Getting it right is hard.
>
> You are technically correct, the best kind of correct.
>
> Seriously though, a bunch of the conversation about shaken/stir and
> various problems with spam callers reveals:
>   "telcos don't care (for any reason you can imagine)"
>   "gov't mandates aren't  really going to help"
>   "people care as recipients of these calls, but really there are
> options for them as well to not get the calls (or not answer them)"
>
> I like that Mr Thomas's answer: "Why can't we just cryptpgraphically
> sign the caller's ANI and use that as a method to ID real callers we
> care about?"
> since that was my suggestion to the stir folk in their very first
> meeting... "what about ebony phones!" said the lawyer from
> telco-ville.
>

Re: QUIC traffic throttled on AT residential

[Ross Tajvar]

Are you suggesting that ATT block all QUIC across their network?

On Tue, Feb 18, 2020, 7:02 PM Ca By  wrote:

>
>
> On Tue, Feb 18, 2020 at 5:44 PM Daniel Sterling 
> wrote:
>
>> I've AT fiber (in RTP, NC) (AS7018) and I notice UDP QUIC traffic
>> from google (esp. youtube) becomes very slow after a time.
>>
>> This especially occurs with ipv4 connections. I'm not the only one to
>> notice; a web search for e.g. "Extremely Poor Youtube TV Performance"
>> notes the issue.
>>
>> I assume traffic is being throttled on AT's side. And it's not done
>> with their CPE; I'm bypassing their NAT box and connecting my laptop
>> directly to the ONT.
>>
>> A quick google search shows people are aware that QUIC can look like
>> DoS traffic -- but how widely known is this problem? It may become
>> worse if / when sites transition to HTTP/3
>>
>> For now I reject UDP 443 on the client firewall. Applications using
>> QUIC client libraries then fallback to TCP. This works well and I have
>> no issues with latency or throughput when using TCP.
>>
>> May I naively ask if Google staff are working with AT to address this?
>
>
> Sounds like you found the answer, ATT just needs to scale up your
> rejection approach that is proven to work well.
>
> Yes, most ddos traffic is ipv4 udp and yes Google was made aware that they
> would be mixing with bad company in the pool of ipv4 udp traffic ... but
> they have reasons.
>
> I am not a fan of quic or any udp traffic. My suggestion was that Google
> use an new L4 instead of UDP, but that was too hard for the Googlers.
>
> So here we are.
>
> Just say no to udp.
>
>
>
>>
>> -- Dan
>>
>

Re: Comcast NOC - Bad IPv6 Routing

[Ross Tajvar]

Interesting - does a v4 traceroute follow the same path? I.e. Richmond CRAN
-> ibone Atlanta -> ibone Ashburn -> Pitt CRAN

Not having detailed knowledge of Comcast's network, I'd expect the Richmond
CRAN has a link to the ibone in Ashburn since it's fairly close (though
there may be a closer ibone location).

On Sat, Feb 15, 2020, 11:11 PM Robert Webb  wrote:

> Could someone from Comcast NOC contact me off list.
>
> Looks like IPv6 routing from Richmond, VA to Grafton, WV has issues. IPSEC
> tunnel between gets less than 5Mbps over IPv6, switching endpoints to IPv4,
> I get the full 25Mbps down capability of the WV connection.
>
> Traceroute looks like below:
>
> Tracing route to 2001:558:6035:3c:79bb:f773:ab2:6bcd over a maximum of 30
> hops
>
>   1<1 ms<1 ms<1 ms  2601:5ca:c301:4c90::1
>   211 ms11 ms10 ms  2001:558:4053:b::1
>   3 7 ms 7 ms 8 ms  2001:558:182:112::1
>   420 ms 9 ms 9 ms
> ae-45-ar02.staplesmllrd.va.richmond.comcast.net [2001:558:180:2005::1]
>   526 ms30 ms24 ms
> be-21508-cr02.56marietta.ga.ibone.comcast.net [2001:558:0:f787::1]
>   622 ms *   23 ms
> be-1202-cs02.56marietta.ga.ibone.comcast.net [2001:558:3:12::1]
>   7 *   28 ms *
> be-1211-cr11.56marietta.ga.ibone.comcast.net [2001:558:3:2::2]
>   8 *** Request timed out.
>   9 *** Request timed out.
>  1036 ms ** be-1402-cr02.ashburn.va.ibone.comcast.net
> [2001:558:3:2d::2]
>  11 *** Request timed out.
>  1239 ms43 ms42 ms  2001:558:380:29c::2
>  1342 ms45 ms50 ms  te-5-1-0-cbr01.taylor.wv.pitt.comcast.net
> [2001:558:382:fe58::2]
>  14 *** Request timed out.
>  15 *** Request timed out.
>  16 *** Request timed out.
>
>
>

Re: FYI - Suspension of Cogent access to ARIN Whois

[Ross Tajvar]

Make sure they send evidence to complia...@arin.net so Cogent doesn't keep
getting away with it.

On Mon, Jan 27, 2020, 2:21 PM Darin Steffl  wrote:

> Cogent is still violating this whois suspension.
>
> A couple wisp's I know were contacted by cogent in the last week after
> receiving their ASN.
>
> On Mon, Jan 27, 2020, 12:57 PM Justin Wilson  wrote:
>
>> This shall be my answer from now on.
>>
>> > On Jan 27, 2020, at 1:22 PM, Dovid Bender  wrote:
>> >
>> > I find it interesting that they say their clients didn't see it as an
>> issue. Whenever they called and asked if I want transit my answer always
>> was when they had v6 peering to He and Gooogle we could talk.
>> >
>>
>>

Re: De-bogonising 2a10::/12

[Ross Tajvar]

There are other options besides Vultr, that's just the one I've used the
most. Check out http://bgp.services.

On Fri, Jan 10, 2020, 12:34 PM Grant Taylor via NANOG 
wrote:

> On 1/10/20 11:01 AM, Ross Tajvar wrote:
> > Couldn't you just get a VPS with Vultr and set up BGP on it?
>
> The last time I looked — it's been a while — doing that was not an
> option for me.
>
> I'll look again to see what the current status is.
>
> Thank you for the pointer.
>
>
>
> --
> Grant. . . .
> unix || die
>
>

More spam

[Ross Tajvar]

FYI, this is a new one for me

-- Forwarded message -
From: Shopee SG Support 
Date: Fri, Jan 10, 2020, 12:10 PM
Subject: [Request Received] Re: De-bogonising 2a10::/12
To: r...@tajvar.io 


Hi Ross Tajvar,


Thank you for contacting Shopee!


Your request has been received and is being reviewed by our Customer
Service Representative.Your reference case# is 43565028.


Kindly allow us up to 1 Working Day(s) to revert back to you. If your
concern is urgent, please contact us via Live Chat or call us at our
customer service hotline +65 6206 6610.


For any concerns in regards to your order purchases, do provide us the
Order ID that you may retrieve as below;


"Me" Tab > My Purchases > Click on the order > Scroll down in the order
details to find Order ID


If you are having issues to log in to your account, please provide below
details;


- Current phone number linked to your Shopee account

- Email address

- Shopee Username


While waiting for our response, you can also find useful information at out
help center at: https://help.shopee.sg


For shipment tracking, you may check the links of our logistic partners
below:

1) https://www.ninjavan.co/en-sg/tracking

2) https://www.speedpost.com.sg/track-and-trace

3) https://roadbull.com/



Operation Hours (Closed during Public Holidays):


Live Chat Support (Shopee App Help Centre) : Monday - Sunday (9:00 AM to
10:00 PM)


Call Hotline: +65 6206 6610, Monday - Friday (9:00 AM to 6:00 PM)


Thank you for your patience and have a great day.



Best Regards,

Shopee Customer Service



ref:_00D6F1oO9b._5006F2WBghc:ref

Re: De-bogonising 2a10::/12

[Ross Tajvar]

Couldn't you just get a VPS with Vultr and set up BGP on it?

On Fri, Jan 10, 2020, 11:44 AM Grant Taylor via NANOG 
wrote:

> On 1/10/20 10:36 AM, Saku Ytti wrote:
> > Much safer, but for me personally, still more downside than upside.
>
> Fair.
>
> I wish that I could get my hands on a DFZ BGP feed.  !R to unprovisioned
> IPs.  }:-)
>
> But that's not easily accessible for mere mortals.
>
>
>
> --
> Grant. . . .
> unix || die
>
>

Re: FYI - Suspension of Cogent access to ARIN Whois

[Ross Tajvar]

Yeah this raises a great point - I'm curious how ARIN is differentiating
between cogent and cogens customers when monitoring for prohibited access.
Particularly those customers whose IPs belong to and are announced by
Cogent.

On Mon, Jan 6, 2020, 10:38 PM Martin Hannigan  wrote:

>
> — shifting a side thread
>
>
> John,
>
> I have no stake in this, so far, but I have a few questions.
>
> Can you define exactly what services have been blocked? IRR/ROA/TLA
> registry updates, etc? Were they blocked ^174 or 174$? This is a precedent
> AFAIK. I’d like to understand consequences. In case I decide to attend
> Dave’s sales training? :-)
>
> Cheers,
>
> -M<
>
>
>
> On Mon, Jan 6, 2020 at 10:45 John Curran  wrote:
>
>> On 22 Sep 2019, at 8:52 AM, Tim Burke  wrote:
>>
>>
>> That is just The Cogent Way™, unfortunately. I just had (yet another)
>> Cogent rep spam me using an email address that is _only_ used as an ARIN
>> contact, trying to sell me bandwidth. When I called him out on it, with
>> complia...@arin.net CCed, he backpedaled and claimed to obtain my
>> information from Google.
>>
>>
>> ARIN has repeatedly informed Cogent that their use of the ARIN Whois for
>> solicitation is contrary to the terms of use and that they must stop.
>> Despite ARIN’s multiple written demands to Cogent to cease these prohibited
>> activities, ARIN has continued to receive complaints from registrants that
>> Cogent continues to engage in these prohibited solicitation activities.
>>
>> For this reason, ARIN has suspended Cogent Communications’ use of
>> ARIN’s Whois database effective today and continuing for a period of six
>> months.  For additional details please refer to
>> https://www.arin.net/vault/about_us/corp_docs/20200106_whois_tos_violation.pdf
>>ARIN will restore Cogent’s access to the Whois database at an earlier
>> time if Cogent meets certain conditions, including instructing its sales
>> personnel not to engage in the prohibited solicitation activities.
>>
>> Given the otherwise general availability of ARIN Whois, it is quite
>> possible that Cogent personnel may evade the suspension via various means
>> and continue their solicitation.  If that does occur, please inform us (via
>> complia...@arin.net), as ARIN is prepared to extend the suspension
>> and/or bring appropriate legal action.
>>
>> FYI,
>> /John
>>
>> John Curran
>> President and CEO
>> American Registry for Internet Numbers
>>
>>
>>
>>
>>
>>
>>

Re: ServiceFinder: Ärendenummer 185392

[Ross Tajvar]

I've been getting these too. It'd be nice if the admins could unsubscribe
these people.

On Sun, Dec 29, 2019, 5:26 PM J. Hellenthal via NANOG 
wrote:

> Well if that ain’t just plain spam I don’t know what is!
>
> --
>  J. Hellenthal
>
> The fact that there's a highway to Hell but only a stairway to Heaven says
> a lot about anticipated traffic volume.
>
> On Dec 29, 2019, at 16:18, i...@servicefinder.com wrote:
>
> 
> __
> Vänligen skriv endast ovanför denna markering när du svarar på meddelandet.
> Hej Scott Weeks,
> Tack för din fråga!
>
> Vi har nu registrerat ditt ärende och du kommer inom kort att bli
> kontaktad av oss på Kundservice.
>
> Du kan också få hjälp själv via vårt Support Center på
> www.support.servicefinder.se. 
>
> Du har ärendenummer *185392* – och alla våra ärenden hanteras i den
> turordning som de kommer in.
>
> Vi kontaktar dig så snart vi bara kan, din fråga är viktig för oss.
>
> Ha en fortsatt bra dag,
> --
>
>
> Med vänliga hälsningar
> *Kundservice*
>
> Öppettider: Vardagar 9-17 | Växel: 08-653 00 00 <+468653>
> Hemsida: www.servicefinder.se [image: ServiceFinder.se]
> --
>
> Detta meddelande skickades till sur...@mauigateway.com med hänvisning
> till ärende 185392.
> [[a6e862e24e9f255dfb1e2e9c14f288dfee770f40-1483209862]]
>
>

Re: Thursday: Internet outage eastern Europe Iran and Turkey

[Ross Tajvar]

I'm interested in these events. It might be worth making a separate list
for them?

On Sat, Dec 21, 2019, 6:24 PM Scott Weeks  wrote:

>
>
> --- s...@donelan.com wrote:
> From: Sean Donelan 
>
> I hadn't seen messages about this Internet outage affecting multiple
> countries (Eastern Europe, Turkey and Iran) from Thursday.
>
> Multiple fiber cuts affecting major parts of sub-continents don't happen
> as much any more. Yes, I still remember the day of FIVE (5) simultaneous,
> trans-continental fiber cuts in the USA.  I was busy :-)
>
> I don't know if Internet route diversity has improved... or people aren't
> sending me messages about them anymore.
> -
>
> I have become quite interested in this lately.  I don't send them
> to the list as no one seemed interested when I sent them before.
> For example, India as been turning off the internet like they turn
> the lights:
>
> https://internetshutdowns.in/
>
>
> Kashmir has been without internet for over 100 days:
>
>
> https://guardian.ng/news/world/restive-kashmir-marks-100-days-since-india-stripped-autonomy/
>
> Just think how you'd do anything without internet for 100+ days!
>
>
>
>
> 
> Usually after a country as 3 or 4 major egress points, large-scale
> unintentional internet outages are relatively rare. Countries with only
> 1 or 2 egress points still have lots of problems.
> 
>
> I'm not so sure 3-4 is a large enough number.  Many countries are
> copying China in information repression (among other things) which
> includes building in the ability to turn off internet access
> (internationally as well as intranationally) as their network is
> built out. Funny that one thing something as large as a country
> is afraid of is normal folks talking to each other freely.  They
> really don't like the end-to-end principle. :)
>
> scott
>
>
>
>
>
>
> https://www.bbc.com/news/technology-50851420
>
> Severed fibre optic cables disrupted internet access in parts of eastern
> Europe, Iran and Turkey on Thursday.
>
> The issue, which lasted for about two hours, was caused by multiple fibre
> cables being physically cut at the same time, a highly unusual thing to
> happen.
> [...]
>
>
>

Visible Wireless security contact

[Ross Tajvar]

I'm looking to get in touch with someone on the Visible Wireless security
team. If you have a contact please shoot me their info.

Thanks,
Ross

Re: Gmail email blocking is off the rails (again)

[Ross Tajvar]

You might have better luck emailing the mailops list.

On Tue, Dec 3, 2019, 10:06 PM Matthew Pounsett  wrote:

>
> For some reason Gmail has started blocking mailman administrative emails
> to someone who's an admin on a list I host.  Their SMTP 552 error message
> points to , which
> implies the "problem" is the URLs in the email, but is otherwise completely
> unhelpful.
>
> If anyone here has any pull with Gmail postmasters, could you please
> suggest to them that they whitelist messages that are as consistent and
> well-known as mailman's admin and moderator messages?
>
>
>

Re: Disney+ Streaming

[Ross Tajvar]

Well, not exactly. Each service is still a bunch of shows and movies
bundled together. If you only want to watch one show, you can't just buy
that, you have to buy the whole service.

Of course, there are services where you can buy individual movies and
episodes (Google Play comes to mind). But Netflix, Disney+, Hulu, etc.
don't operate that way.

-Ross

On Thu, Nov 28, 2019, 1:53 PM Owen DeLong  wrote:

> While I agree about the likely outcome, I will point out that consumers
> have been
> begging for unbundling for years.
>
> This fragmentation of streaming services _IS_ the direct result of that
> request.
>
> It’s unbundled service, exactly what they have been asking for.
>
> Owen
>
>
> > On Nov 26, 2019, at 01:54 , Mark Tinka  wrote:
> >
> >
> >
> > On 12/Nov/19 22:36, Brian J. Murrell wrote:
> >
> >>
> >> I actually suspect streaming is going to decline (at least in
> >> comparison to where it could have grown to) if this streaming service
> >> fragmentation continues.
> >>
> >> I think people are going to reject the idea that they need to subscribe
> >> to a dozen streaming services at $10-$20/mo. each and will be driven
> >> back the good old "single source" (piracy) they used to use before 1
> >> (or perhaps 2) streaming services kept them happy enough to abandon
> >> piracy.
> >>
> >> The content providers are going to piss in their bed again due to
> >> greed.  Again.
> >
> > This!
> >
> > At the beginning of this year, I dumped Prime Video because while I
> > initially got it for "The Grand Tour", almost all the other content was
> > not available in Africa. Didn't see the point of shelling out over
> > US$100/year for just one show, especially since we already have Netflix
> > + a local linear pay TV service.
> >
> > I bought the wife a new iPhone 11 Pro earlier this month. This got us
> > 1-year's worth of free AppleTV+. Not a lot of content so far, but I hear
> > the same about Disney+. Granted 2 of the 3 shows on TV+ are not bad. But
> > it's free, so what the heck.
> >
> > I'm not keen on paying for more than one streaming service, if I'm
> > honest. There already isn't enough time in the world for regular life,
> > never mind watching one streaming service... now we have to deal with
> > more, each with their own price? Not sure how well the streaming
> > providers expect regular folk to take all of this fragmentation.
> >
> > As my daughter would say, "They can miss me with it :-)".
> >
> > Mark.
> >
>
>

Re: AT released DANOS code to Linux Foundation

[Ross Tajvar]

For an additional point of reference - I run two Edgerouter Pros with
multiple full tables (v4 and v6). One of them is fine, but one of them
crashes and reboots about once a week. I'm currently trying to replace
them, possibly with DANOS now that it's out.

On Mon, Nov 18, 2019 at 4:23 PM Brielle  wrote:

> On 11/18/2019 2:12 PM, Mike Hammett wrote:
> > Chances are, if there was a decision to be made, UBNT made the wrong
> choice.
> >
> > That said, I've heard a lot of good about ZebOS.  *shrugs*
>
> Well, early on during the switch there was a few issues with the change.
>   For example, I had to fix the support for various IPv6 bits like 6rd.
>
> It really should have been labeled as a major release (1.0 -> 2.0)
> instead of an incremental (1.x to 1.x+1)...  but hindsight and all.
>
> That being said, I do run a few EdgeRouter Infinities with OSPF and BGP
> (taking full tables for v4 and v6) and they've not had glaring issues
> for any of my uses.
>
> Some people just upgrade WAYY too quickly without doing proper bench
> testing - and it always bites you in the ass in the end.
>
> --
> Brielle Bruns
> The Summit Open Source Development Group
> http://www.sosdg.org/ http://www.ahbl.org
>

Re: Iran cuts 95% of Internet traffic

[Ross Tajvar]

Do we have any ideas which prefixes are still accessible?

On Mon, Nov 18, 2019 at 3:01 PM Scott Fisher  wrote:

> One would hope so, but I am I sure they will just threaten their
> population on using it. Tyrannical regimes know no bounds.
>
> Thanks,
> Scott Fisher
> Team Cymru
>
> On 11/18/19 2:26 PM, Tony Wicks wrote:
> >>Implementation specifics vary. Most rely on state control of consumer
> > ISPs and implement a variety of systems at that layer. Many also have
> > chokepoints for >international connectivity as well.
> >
> >
> >
> > I guess all these governments who like to control access so tightly are
> > going to be in a total tailspin over Starlink eh.
> >
> >
> >
> >
> >
> >
> >
>
>

Re: Disney+ Streaming

[Ross Tajvar]

I think it would be more on topic if everyone weren't just guessing what
users will do based on hypothetical behavior patterns and hypothetical
content shifts.

I WOULD be interested to see some data showing e.g. a drop in traffic to
one service and a boost in traffic to another service when a particular bit
of media was moved from the former to the latter. (Or a boost in both, etc.)

On Wed, Nov 13, 2019, 11:04 AM Stephen Satchell  wrote:

> CAVAET: I don't have a dog in this hunt.
>
> On 11/13/19 6:46 AM, Mel Beckman wrote:
> > This is silly off-topic. You don’t have to go home, but you can’t
> > stay here, according to NANOG guidelines.
>
> > https://www.nanog.org/resources/usage-guidelines/ >
> https://www.nanog.org/bylaws/
>
> "The NANOG mailing list was established in 1994 to provide an open forum
> for the exchange of technical information, and lively discussion of
> SPECIFIC IMPLEMENTATION CHALLENGES (emphasis mine) that require
> cooperation among network service providers.
>
> "Posts to NANOG’s mailing list should be focused on operational and
> technical content only, as described by the NANOG Bylaws."
>
> Yes, some of the Disney Plus thread has strayed outside the four corners
> of the rules of the mailing list, but the bulk of the thread has to do
> with two things: geolocation inaccuracies, and traffic capacity shifts.
>   For some network operators on this list, the discussion does not
> describe issues on their networks.  But "some" is not "all".
>

Re: T-Mobile help!!

[Ross Tajvar]

You may want to try VoiceOps:
https://puck.nether.net/mailman/listinfo/voiceops.

On Thu, Oct 31, 2019 at 9:05 AM David Funderburk 
wrote:

> One of our customers office number is coming across as 'Survey Call' on
> T-Mobile cell phones.  I know with certainty it's with 'T-Mobile' phones.
> I don't have another contact on another network that I know I can try.  How
> do we get that fixed?
>
> Thanks for any suggestions!
> --
> Regards,
>
> David Funderburk
> GlobalVision
> 864-569-0703
>
> For Technical Support, please email gv-supp...@globalvision.net
>
> GlobalVision is a communications company that provides services which
> includes Internet, internal and external networks with over 25 years
> experience. With our Zero Downtime strategies we help companies increase
> up-time and decrease lost productivity and costs.
>
> --
> This message has been scanned for viruses and dangerous content by
> *E.F.A. Project* , and is believed to be
> clean.
>

Re: Anyone from NTT America here?

[Ross Tajvar]

What was the source/destination?

On Wed, Oct 23, 2019, 2:10 PM Stephen Satchell  wrote:

> Routing loop
>
> >  11.|-- 129.250.24.196 0.0% 1   28.9  28.9  28.9  28.9
>  0.0
> >  12.|-- 129.250.130.2540.0% 1   29.0  29.0  29.0  29.0
>  0.0
> >  13.|-- 129.250.130.2530.0% 1   29.4  29.4  29.4  29.4
>  0.0
> >  14.|-- 129.250.130.2540.0% 1   29.6  29.6  29.6  29.6
>  0.0
> >  15.|-- 129.250.130.2530.0% 1   28.5  28.5  28.5  28.5
>  0.0
> >  16.|-- 129.250.130.2540.0% 1   29.0  29.0  29.0  29.0
>  0.0
> >  17.|-- 129.250.130.2530.0% 1   28.6  28.6  28.6  28.6
>  0.0
> >  18.|-- 129.250.130.2540.0% 1   27.9  27.9  27.9  27.9
>  0.0
> >  19.|-- 129.250.130.2530.0% 1   28.4  28.4  28.4  28.4
>  0.0
> >  20.|-- 129.250.130.2540.0% 1   27.9  27.9  27.9  27.9
>  0.0
> >  21.|-- 129.250.130.2530.0% 1   28.2  28.2  28.2  28.2
>  0.0
> >  22.|-- 129.250.130.2540.0% 1   29.0  29.0  29.0  29.0
>  0.0
> >  23.|-- 129.250.130.2530.0% 1   27.9  27.9  27.9  27.9
>  0.0
> >  24.|-- 129.250.130.2540.0% 1   28.6  28.6  28.6  28.6
>  0.0
> >  25.|-- 129.250.130.2530.0% 1   28.7  28.7  28.7  28.7
>  0.0
>

Re: BGP Enabled transit in Chicago (River North) and equipment

[Ross Tajvar]

If you're okay with a tunnel, you may want to check out http://bgp.services.

On Wed, Oct 16, 2019 at 8:36 AM John Palmer  wrote:

> I've got a Cisco 881 with the "Advanced IP features" This will do for what
> I'm
> trying to accomplish.
>
> I think I'm going to go with a BGP tunnel.
>
> No one at RCN has any clue about this - they may not even provide the
> server. The sales
> droids only know how to sell their pre-packaged plans.
>
> Does anyone know who provides BGP tunnel session?  Doesn't really need to
> be RCN as I can create a tunnel with any peer.
>
> Thanks
> >
> > They are obviously not running full tables on their 3640. I'd imagine a
> > raspberry pi would have more BGP capability and throughput than a 3640,
> > though I don't recommend doing that even as a joke. But an ERR would be
> > fine if they're expecting nothing more than a slightly faster 3640 with
> > maybe some extra features.
> >
> > On 9/3/19 3:54 PM, Florian Brandstetter via NANOG wrote:
> > > Ubiquiti's EdgeRouter Lite is equipped with 512 MiB of DDR2 memory, of
> > > which after startup, roughly 491 MiB can be utilized. 119 MiB of the
> > > remaining memory are allocated by the base of the router already,
> > > which leaves you with a remainder of 372 MiB memory. Memory usage
> > > depends on the architecture for objects, for example there's a large
> > > difference between x86 and x86_64, since on x86_64, the compiler will
> > > generally use 64bit boundaries to be faster; the ERL runs on a MIPS64
> > > architecture, which will have a similar trade-off. To get to the
> > > point, let's have a quick look at the components using memory: bgpd,
> > > zebra, kernel. Roughly 180 MiB of memory are required to keep a single
> > > full table in bgpd alone, leaving you with 192 MiB of free memory.
> > > Accounting further, zebra will eat at least another 100 MiB for
> > > exporting the BGP RIB to the Kernel (FIB), leaving you with 100 MiB.
> > > At this point, you have a mere 92 MiB left for fitting the routes into
> > > the kernel, and to leave room for RX buffers on sockets.
> > >
> > > I don't see full tables happening from a memory perspective on the
> > > EdgeRouter Lite, you would want to look at something with at least 2
> > > GiB of memory to keep the whole system running smoothly, and when
> > > using Quagga and Zebra, that's still aimed rather low. FRRouting at
> > > this point uses 2 GiB for 4 full tables on an x86 system, without any
> > > magic attached.
> > >
> > > Having kept it unmentioned, the EdgeRouter Lite has a dual-core with
> > > 500 MHz, and surely your BGP updates processing isn't offloaded, hence
> > > you will pretty quickly kill the whole router when you flood it with a
> > > full table, unless you set very low queue sizes, which isn't really
> > > reliable though since you generally want BGP to converge fast - not
> > > after a period of 15 minutes with the CPU sitting on 100%.
> > >
> > > You might want to install something like OpenWRT (which I don't know
> > > the possibility of on an ERL), and run BIRD if you're tied to a low
> > > memory footprint, however, in a base vendor-generic setup of the ERL,
> > > it's beyond my understanding why one would even suggest running a full
> > > table on it.
> > > Sent from Mailspring
> >
> > --69793807A24007030ACBABEA
> > Content-Type: text/html; charset=utf-8
> > Content-Transfer-Encoding: 7bit
> >
> > 
> >   
> > 
> >   
> >   
> > They are obviously not running full tables on their 3640. I'd
> >   imagine a raspberry pi would have more BGP capability and
> >   throughput than a 3640, though I don't recommend doing that even
> >   as a joke. But an ERR would be fine if they're expecting nothing
> >   more than a slightly faster 3640 with maybe some extra
> features.
> > 
> > On 9/3/19 3:54 PM, Florian Brandstetter
> >   via NANOG wrote:
> > 
> >  >   cite="mid:69414933-770b-464c-b9da-a8f7a6156...@getmailspring.com">
> >   
> >   Ubiquiti's EdgeRouter Lite is equipped with 512 MiB of DDR2
> > memory, of which after startup, roughly 491 MiB can be utilized.
> > 119 MiB of the remaining memory are allocated by the base of the
> > router already, which leaves you with a remainder of 372 MiB
> > memory. Memory usage depends on the architecture for objects,
> > for example there's a large difference between x86 and x86_64,
> > since on x86_64, the compiler will generally use 64bit
> > boundaries to be faster; the ERL runs on a MIPS64 architecture,
> > which will have a similar trade-off. To get to the point, let's
> > have a quick look at the components using memory: bgpd, zebra,
> > kernel. Roughly 180 MiB of memory are required to keep a single
> > full table in bgpd alone, leaving you with 192 MiB of free
> > memory. Accounting further, zebra will eat at least another 100
> > MiB for exporting the 

Re: Twilio

[Ross Tajvar]

They do a lot of things. It might help to specify what you're having issues
with.

On Wed, Oct 2, 2019, 7:51 PM Ben Cannon  wrote:

> Can an engineer for Twilio please reach out to me off-list if possible?
> Thanks.
> -Ben.
>
> -Ben Cannon
> CEO 6x7 Networks & 6x7 Telecom, LLC
> b...@6by7.net
>
>
>
>

Re: ISP Job

[Ross Tajvar]

You haven't answered the question about your credentials, though.

On Mon, Sep 23, 2019, 8:48 PM David Ratkay  wrote:

> To give some more info I live in South Bend, Indiana. So Michigan actually
> could be an option.
>
> On Mon, Sep 23, 2019, 4:01 AM David Ratkay  wrote:
>
>> I have been looking to work at an ISP for a long time now. I live in
>> Northern Indiana in the US and there seems to not be much opportunities to
>> work for an ISP in this region. Any recommendations?
>>
>

Re: Cogent sales reps who actually respond

[Ross Tajvar]

Ah, sorry, I didn't understand your message. Nevermind.

On Mon, Sep 16, 2019 at 8:53 PM Ross Tajvar  wrote:

> > 1. Sprint peering battle. Google it
>> > 2. He.net peering battle. Google it.
>> > 3. Google IPv6 peering battle. Google it.
>> >
>> > All of which point to them being pompous assholes.
>>
>> or point to them treating ipv6 the same as ipv4 when it comes to
>> peering, tech, ...  we are supposed to think ipv6 parity is a good
>> thing.
>>
>
> Can you elaborate on this? What are they doing/not doing that you take
> issue with?
>

Re: Cogent sales reps who actually respond

[Ross Tajvar]

>
> > 1. Sprint peering battle. Google it
> > 2. He.net peering battle. Google it.
> > 3. Google IPv6 peering battle. Google it.
> >
> > All of which point to them being pompous assholes.
>
> or point to them treating ipv6 the same as ipv4 when it comes to
> peering, tech, ...  we are supposed to think ipv6 parity is a good
> thing.
>

Can you elaborate on this? What are they doing/not doing that you take
issue with?

Re: Consistent routing policy?

[Ross Tajvar]

>
> https://archive.nanog.org/meetings/nanog40/presentations/BGPcommunities.pdf
>

Don’t let anyone send you Informational tags, these should only be set by
> you, and you should strip them from all BGP neighbors (customers, transits,
> peers, etc). Otherwise you have a massive security problem.


I often see informational tags propagated through multiple ASes. What is
the security risk there?

Re: Comcast route server not reflecting their reality

[Ross Tajvar]

>
> IIRC, Comcast uses "local-as 7922" path rewriting for all enterprise EDI
> customers
> running BGP off of regional CRANs, unless I'm mistaken.  So if your
> regional CRAN
> is as7015 (for New England), even if your physical circuit and BGP session
> land
> on a local SUR in your area, you have to use remote-as 7922 to setup the
> session
> with Comcast ENS, regardless of the fact that actual peer's router is
> using as7015.
>

This totally makes sense, thanks for the explanation!

Re: Comcast route server not reflecting their reality

[Ross Tajvar]

>
> Unlike AS2914 which purely interconnects with AS7922, it seems that AS3356
> also has direct interconnections to the various Comcast subsidiary
> networks which are hidden from the DFZ through no-export communities.


I'm curious how this works and why it's done this way. I have a friend who
has transit from AS7922 (the remote AS in his BGP sessions are all 7922),
but CenturyLink's looking glass shows an AS path of "33657 " and
includes the no-export community. Why is the AS path rewritten? What is the
design here?

-Ross

Re: BGP Enabled transit in Chicago (River North) and equipment recommendation

[Ross Tajvar]

I will note that Comcast will do BGP on their enterprise fiber circuits.
Comcast DIA (which they call EDI) comes in increments of 1M up to 10M, then
10M up to 100M, etc. So you could get 10M or 80M (not sure if "10MB/Sec"
means 10Mbps or 80MBps) and do BGP over that, if it's available. RCN is
likely similar but I'm not as familiar with their offerings.

On Tue, Sep 3, 2019 at 3:35 PM Brielle  wrote:

> On 9/3/2019 12:19 PM, Matt Harris wrote:
> > But even the higher-end Ubiquiti EdgeRouter series products can handle
> > full tables if you understand and accept their limitations in doing so
> > if budget is a huge concern but you still need to take full tables.
>
> As long as you stick with the 1.10.10 series of firmware, the EdgeRouter
> series is pretty stable.  I run an EdgeRouter Infinity (8 x 10G SFP+) at
> home with both IPv4 and IPv6 BGP feeds on a CenturyLink Fiber+ connection.
>
> You can get the original EdgeRouter Lite for sub $100 and it will have
> no problem taking a full feed for both v4 and v6...  However, better
> choice is the EdgeRouter 4, which is a bit newer and much faster.
>
> There's also the ER6P if you need something with more ports, or even the
> ER12/12P if you want something with a built in network switch.  Just
> avoid the budget oriented ERX and ER10X which lack the RAM.
>
> All of the ERs are low power consumption and Linux based with a
> Vyatta/VyOS/Juniper-like CLI, so pretty easy to work with.
>
> (I do Ubiquiti deployments, so can answer a lot of questions anyone
> might have).
>
> --
> Brielle Bruns
> The Summit Open Source Development Group
> http://www.sosdg.org/ http://www.ahbl.org
>

Re: Mx204 alternative

[Ross Tajvar]

I'd like to register my interest as well. I think an open hardware platform
will do a lot to move the industry forward.

On Mon, Sep 2, 2019, 10:09 PM Brandon Martin 
wrote:

> On 9/2/19 6:04 PM, Mark Tinka wrote:
> >> Like how about 8-16*100GE single Trio PCI card with no-questions
> >> asked, specification released, would there be a market? I like to
> >> think there would be.
> > I'd be down for this.
> >
> > Mark.
>
> Oh my gosh this.  Especially if the docs are truly public (i.e.
> available with single click-wrap "don't be an asshat" license or even
> something like GDFL) and not just under NDA, but honestly even if it's
> an NDA required as long as it's broadly available for issuance (no need
> to be a high-volume) Broadcom partner and allows the results of its use
> to be distributed as F/OSS software, I'm game.
>
> I kinda wonder if the culture at Broadcom has changed any since the
> merger/acquisition with Avagao.  Obviously in ye olde days, you wouldn't
> even get the time of day from them unless you were wanting to commit to
> a million or so in sales.
>
> I spread my interest (and professional practice) between SP networking,
> industrial networking, industrial controls, and industrial computing
> including hardware, so this is drool-level interest for me even if I
> don't get to work on it directly.  So much so that I've been wanting to
> play with an FPGA platform for this sort of thing, but there's just no
> compelling reason given that existing, openly-documented accelerated
> NICs from e.g. Intel on high-end PC hardware can basically match the
> performance of any reasonable-cost FPGA Ethernet switching system in
> useful workloads.
> --
> Brandon Martin
>

Re: Weekly Routing Table Report

[Ross Tajvar]

Is anyone else getting flashbacks to the guy who said he solved the spam
problem?

I don't think this conversation is going anywhere productive.

On Mon, Sep 2, 2019 at 1:05 AM Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:

> Owen DeLong wrote:
>
> > My knowledge in this case is having been an HE employee for several
> > years. Admittedly, that was some time ago, but I am pretty sure I would
> > have heard of any major acquisitions by HE.
>
> If you think we should blindly believe your unfounded statement
> not supported by any verifiable reference, that is the
> condescending behavior.
>
>  > You offer no counter-argument nor any reason that my knowledge is
>  > inaccurate,
>
> I'm saying your opinion is untrustworthy.
>
> Masataka Ohta
>

Re: Weekly Routing Table Report

[Ross Tajvar]

> There are other articles, some of which are peer reviewed papers,
> describing details.

Can you link those?

Re: Weekly Routing Table Report

[Ross Tajvar]

> I don't think I need such chance as my argument is already good enough.

I'm curious if you're able to convince anyone that your thoughts are valid
and correct with such an attitude.

Re: Looking for a Google contact (peering frustrations)

[Ross Tajvar]

What was the outcome?

On Tue, Aug 27, 2019, 8:35 PM Jon Sands  wrote:

> Fixed off list by (several) google employees. Thanks!
>
> On 8/26/2019 10:52 PM, Jon Sands wrote:
> > AS397031 here, located in Telehouse (7 Teleport). We picked up a port
> > on NYIIX specifically to peer with google and cloudflare. We were
> > doing around 6gbps inbound from google over the NYIIX for some time
> > then without warning google withdrew routes from us, I'm guessing
> > because too much bandwidth over an IIX and they prefer a private
> > interconnect at that point. So we requested to peer with them via a
> > PNI and were denied, saying they can't do that either as they're not
> > located in any Telehouse buildings. So I'm left with no Google peering
> >
> > A 10gb wave from where we are to the nearest google peering point is
> > basically the same cost as 10gbps from HE, so trying to figure out my
> > best options here. Open to suggestions! Ideally we would love to peer
> > with google again over NYIIX if possible.
> >
>
> --
> Jon Sands
> MFI Labs
> https://fohdeesha.com/
>
>

Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17

[Ross Tajvar]

Seems like submitting a fraud request to ARIN is more effective than
writing a novel and sending it to NANOG, and doesn't require the latter...

On Mon, Aug 12, 2019, 3:16 PM John Curran  wrote:

> On 9 Aug 2019, at 4:09 PM, Ronald F. Guilmette 
> wrote:
> > ...
> > Unfortunately, we cannot read too much into this change that was made
> > to the block's public-facing WHOIS record.  Neither the new WHOIS info
> > nor even the old WHOIS info can be used to reliably infer who or what
> > is the legitimate registrant of the block at any point in time.  This
> > is because ARIN, like all of the other Regional Internet Registries,
> > allows registrants to put essentially any bovine excrement they desire
> > into their public-facing WHOIS records.
>
> Ronald -
>
> That is not the case – ARIN confirms the legal status of organizations
> receiving number resources.
>
> >  (And, it should be noted, the
> > man behind the recent large scale "Micfo" fraud apparently availed
> > himself of this exact opportunity far subterfuge, in spades.)
>
> As previously noted on this list, such was only possible because of the
> use of falsely notarized documents.
>
> > Regardless, the available records suggest that there are only two likely
> > possibilities in this case:
> >
> > 1) On or about 02-17-2010 HHSI, Inc. (California) transfered the
> >registration of the 216.179.128.0/17 block from itself to the
> >2009 vintage Delaware entity Azuki, LLC.  If this is what
> happened,
> >then it is likely that the transfer was performed in violation
> >of the applicable ARIN trasfer policy that was in force at the
> time.
> >(Azuki, LLC did not simply buy-out HHSI, Inc., lock, stock, and
> >barrel in 2010.  California records show that HHSI, Inc. continued
> >to be an active California corporation until at least 02/12/2014,
> >and probably well beyond that date.)
> >
> > 2) Alternatively, on or about 02-17-2010 HHSI, Inc. (California)
> simply
> >altered what would henceforth appear in the public-facing WHOIS
> >record for the the 216.179.128.0/17 block to make it appear... to
> >everyone except ARIN staff, who knew better... that the block was
> >now registered to Azuki, LLC in Delaware.
> >
> > Only ARIN staff can tell us which of these possibilities actually
> applies.
> > But due to ARIN's strict adherence to contractual confidentiality with
> > respect to all of their resource holders, I do not anticipate that ARIN
> > will actually provide any clarity on this case anytime soon.
>
> That is easy to address:  submit a fraud request, and it will be reviewed
> and corrected if it was done fraudulently.
>
> Thanks!
> /John
>
> John Curran
> President and CEO
> American Registry for Internet Numbers
>
>
>

Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17

[Ross Tajvar]

First he thought that a /17 got stolen (by creating a company with the same
name as the original, now-defunct owner), but he then said he was wrong and
actually it either 1) got transferred against ARIN policy or 2) was made to
look like it was transferred by altering the whois data.

On Fri, Aug 9, 2019, 4:47 PM Töma Gavrichenkov  wrote:

> Peace,
>
> On Thu, Aug 8, 2019 at 10:54 PM Ronald F. Guilmette
>  wrote:
> > Corporate identity theft is a simple ploy which may be used to illicitly
> > obtain valuable IPv4 address space.  Actual use of this fradulent ploy
> > was first described publicly in April, 2008 (https://wapo.st/2YLEhlZ).
>
> nostromo:tmp ximaera$ wc guilmette_combined.mbox
>  2492122   13695 guilmette_combined.mbox
> nostromo:tmp ximaera$
>
> I wish I had enough spare time to read this.
>
> May we have a tl;dr version of this?
>
> --
> Töma
>

Re: Best ways to ensure redundancy with no terrestrial ISPs

[Ross Tajvar]

Hi Eric, thanks for this info. Very helpful.

Mark/everyone, this is in Morocco specifically. I haven't been given the
exact location but I'm told it's near Dahkla.

On Sat, Aug 3, 2019, 9:36 PM Eric Kuhnke  wrote:

> In a remote area in northern africa if there are no terrestrial ISPs, and
> there is no budget to build towers for PTP microwave, I don't know if there
> are any reasonable options.
>
> If sufficient funds did exist, my recommendation, if they really want true
> diversity between two totally different services, would be a combination of
> a MEO o3b earth station and a traditional geostationary type earth station
> (Ku band) with appropriate RF chain and SCPC modem.
>
> It is also possible to achieve full diversity through two totally separate
> geostationary earth stations, using different satellite transponders and
> different teleports on the other end.
>
> But that's not going to be cheap, either in a one time equipment cost or
> in monthly recurring cost, for o3b services and transponder kHz lease +
> teleport services on the other end somewhere in continental Europe.
>
> On Sat, Aug 3, 2019 at 2:10 PM Ross Tajvar  wrote:
>
>> On Sat, Aug 3, 2019 at 4:30 PM Brian Henson  wrote:
>>
>>> If we had a location (or at least a part of the world) we might be able
>>> to recommend a little better.
>>>
>>
>> This is in northern Africa.
>>
>

Re: Xfinity with IPv6 clue?

[Ross Tajvar]

Did you get in touch with someone? What was the problem?

On Sun, Aug 4, 2019, 9:50 PM Janet Sullivan  wrote:

> Nanog is magical.  I have working IPv6 now.
>
>
>
> *From:* Janet Sullivan
> *Sent:* Sunday, August 4, 2019 6:29 PM
> *To:* 'nanog@nanog.org' 
> *Subject:* Xfinity with IPv6 clue?
>
>
>
> I hate resorting to NANOG, but I’ve spent over 5 hours on the phone with
> Xfinity the past two days, and I can’t seem to get someone who understands
> my problem.
>
>
>
> I do not have working IPv6 – I do not get an address or PD.  I have
> working IPv4.  Xfinity wanted to blame this on my modem, so I went and
> picked up a Xfinity modem.  From the 10.0.0.1 web site on the xfinity
> modem, I can ping IPv4 addresses fine.  I can not ping IPv6 addresses from
> the modem itself, thus taking my equipment out of the picture.  This is a
> new activation.  Xfinity keeps asking questions like “well, can you surf
> the internet”, which shows that they seem to totally lack understanding.
> I’ve talked to at least 7 people, and have reached my breaking point.   I
> know, I know, its residential and I should have low expectations.  I’m
> sorry for the noise, but I can’t seem to find anyone with clue.
>

Re: Best ways to ensure redundancy with no terrestrial ISPs

[Ross Tajvar]

On Sat, Aug 3, 2019 at 4:30 PM Brian Henson  wrote:

> If we had a location (or at least a part of the world) we might be able to
> recommend a little better.
>

This is in northern Africa.

Re: Best ways to ensure redundancy with no terrestrial ISPs

[Ross Tajvar]

Not that I know of, especially given the location. I'll look into it though.

On Sat, Aug 3, 2019, 3:42 PM Mike Hammett  wrote:

> Any existing WISPs?
>
>
>
> -
> 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: *"Ross Tajvar" 
> *To: *"North American Network Operators' Group" 
> *Sent: *Saturday, August 3, 2019 2:30:43 PM
> *Subject: *Best ways to ensure redundancy with no terrestrial ISPs
>
> Hi all,
>
> A friend of mine is trying to set up a network in a location where there
> is no fiber (or copper) for many miles. As bandwidth requirements are low
> (<1M for the foreseeable future) but uptime is important, he was looking at
> using multiple cell modems from separate carriers as redundant uplinks. I
> am concerned that different cell carriers might be using the same transport
> providers to a given tower, so that wouldn't be truly redundant. Another
> option would be using a satellite provider as a backup for cellular. (The
> high latency that comes with satellite is not an issue.)
>
> A fixed-radio solution would likely be too expensive upfront as it would
> require building towers.
>
> Am I missing any other options or considerations?
>
> Thanks,
> Ross
>
>

Best ways to ensure redundancy with no terrestrial ISPs

[Ross Tajvar]

Hi all,

A friend of mine is trying to set up a network in a location where there is
no fiber (or copper) for many miles. As bandwidth requirements are low (<1M
for the foreseeable future) but uptime is important, he was looking at
using multiple cell modems from separate carriers as redundant uplinks. I
am concerned that different cell carriers might be using the same transport
providers to a given tower, so that wouldn't be truly redundant. Another
option would be using a satellite provider as a backup for cellular. (The
high latency that comes with satellite is not an issue.)

A fixed-radio solution would likely be too expensive upfront as it would
require building towers.

Am I missing any other options or considerations?

Thanks,
Ross

Re: Help needed configure a server

[Ross Tajvar]

Peter,

You might want to check out reddit, specifically r/homelab. That subreddit
has a lot of good resources for the type of stuff you've described (check
the wiki).

This mailing list is more aimed at enterprise-level networking, so probably
not the best place to ask these kind of questions.

Best,
Ross

On Thu, Aug 1, 2019 at 1:57 PM Matt Harris  wrote:

> Hi Peter,
> I might suggest that you start at the beginning, perhaps with google or
> some classes - either something in person, or maybe just some introductory
> videos online that discuss entry level IT topics.
>
> As far as recommended hardware, a raspberry pi may be a quick, inexpensive
> way to get started.
>
> Good luck!
>
>
> On Thu, Aug 1, 2019 at 12:48 PM peter agakpe  wrote:
>
>> I am a newbie trying to configure and put a home server online as starter
>> project.  with some help. Specifically, dns server specifics, port
>> forwarding, recommended hardware and software, such as router, dns server,
>> security, etc. I would greatly appreciate any help.
>>
>>
>>
>> Thanks
>>
>> Peter
>>
>>
>>
>> Sent from Mail  for
>> Windows 10
>>
>>
>>
>
>
> --
> Matt Harris - Chief Security Officer
> Security, Compliance, and Engineering
> Main: +1-816-256-5446
> Mobile: +1-908-590-9472
> Email: m...@netfire.net
>

Re: 240/4 (Re: 44/8)

[Ross Tajvar]

>  Editor's note: This draft has not been submitted to any formal
>  process.  It may change significantly if it is ever submitted.
>  You are reading it because we trust you and we value your
>  opinions.  *Please do not recirculate it.*  Please join us in
>  testing patches and equipment!

(emphasis mine)

Interesting choice to host it in a public Github repo, then...

On Mon, Jul 22, 2019 at 11:17 PM Mikael Abrahamsson 
wrote:

> On Mon, 22 Jul 2019, Owen DeLong wrote:
>
> >   2.  It was decided that the effort to modify each and every IP
> stack in order to facilitate use of this relatively small block (16 /8s
> being evaluated against a global
> >   run rate at the time of roughly 2.5 /8s per month, mostly
> to RIPE and APNIC) vs. putting that same effort into modifying each and
> every IP stack to support
> >   IPv6 was an equation of very small benefit for slightly
> smaller cost. (Less than 8 additional months of IPv4 free pool vs.
> hopefully making IPv6 deployable
> >   before IPv4 ran out).
>
> Well, people are working on making 240/4 usable in IP stacks:
>
>
> https://raw.githubusercontent.com/dtaht/unicast-extensions/master/rfcs/draft-gilmore-taht-v4uniext.txt
>
> There have been patches accepted into some BSDs and into Linux
> tools/kernel and other operating systems to make 240/4 configurable and
> working as unicast space.
>
> I don't expect it to show up in DFZ anytime soon, but some people have
> dilligently been working on removing any obstacles to using 240/4 in most
> common operating systems.
>
> For controlled environments, it's probably deployable today with some
> caveats. I think it'd be fine as a compliment to RFC1918 space for some
> internal networks.
>
> --
> Mikael Abrahamssonemail: swm...@swm.pp.se
>

Re: Microsoft Outlook Issue

[Ross Tajvar]

Good to know, but this is probably better suited for the Outages mailing
list.

On Fri, Jul 19, 2019 at 12:51 PM Nathanael Catangay Cariaga <
ncari...@gmail.com> wrote:

> Taken from MS O365 Health Portal:
>
> *Title: Can't access email User Impact: Users may be unable to connect to
> the Exchange Online service. More info: Other services with dependencies on
> Exchange Online, such as calendar access through Microsoft Teams, could
> also be intermittently unavailable. Current status: We're continuing to
> repair the communication issue between mailbox-hosting infrastructure and
> components that facilitate access and other users actions. In parallel,
> we're exploring additional potential mitigation actions to more quickly
> restore service. Scope of impact: This issue could potentially affect any
> of your users if they are routed through the affected infrastructure. Start
> time: Friday, July 19, 2019, at 9:30 AM UTC Root cause: A potential
> communication issue between service components that host the affected
> mailboxes and infrastructure that facilitates user connections is affecting
> access to Exchange Online. Next update by: Friday, July 19, 2019, at 5:30
> PM UTC*
>
> On Sat, Jul 20, 2019 at 12:38 AM Ross Tajvar  wrote:
>
>> What's the issue?
>>
>> On Fri, Jul 19, 2019 at 12:35 PM Nathanael Catangay Cariaga <
>> ncari...@gmail.com> wrote:
>>
>>> This might be an off topic since this is a confirmed issue
>>> with Microsoft but I'm just wondering how vast are the affected users on
>>> this issue.
>>>
>>> west coast user here.
>>>
>>>
>>> -nathan
>>>
>>

Re: Microsoft Outlook Issue

[Ross Tajvar]

What's the issue?

On Fri, Jul 19, 2019 at 12:35 PM Nathanael Catangay Cariaga <
ncari...@gmail.com> wrote:

> This might be an off topic since this is a confirmed issue with Microsoft
> but I'm just wondering how vast are the affected users on this issue.
>
> west coast user here.
>
>
> -nathan
>

Re: netstat -s

[Ross Tajvar]

> but could you answer my question?

Just seemed like there was some urgency so I was curious.

On Thu, Jul 18, 2019, 5:57 PM Randy Bush  wrote:

> > Why do you want to know?
>
> why do you want to know why i want to know?  :)
>
>

Re: netstat -s

[Ross Tajvar]

Why do you want to know?

On Thu, Jul 18, 2019, 5:55 PM Randy Bush  wrote:

> > Ideally folks should be subshells (unless you're on a strange system or
> > legacy system).
> >
> > netstat is now mostly obsolete.
> > Replacement for netstat is ss.
> > Replacement for  netstat -r is ip route.
> > Replacement for netstat -i is ip -s link.
> > Replacement for netstat -g is ip maddr.
>
> on some vendors.  but could you answer my question?  do you use it?
>

Re: Twitter security team?

[Ross Tajvar]

Why is Hacker one wrong? Seems like this would be exactly what it's for.

On Thu, Jul 18, 2019, 3:04 PM J. Hellenthal via NANOG 
wrote:

> Or maybe a tweet to @twittersecurity
>
> > On Jul 18, 2019, at 13:59, J. Hellenthal  wrote:
> >
> >
> > Yes/No ?
> >
> >
> https://help.twitter.com/en/rules-and-policies/reporting-security-vulnerabilities
> >
> >> On Jul 18, 2019, at 13:45, Ken Gilmour  wrote:
> >>
> >> Anyone on the list know how to contact the Twitter Security team?
> >>
> >> Seems the new update allows an attacker to modify other people's
> tweets. The "Hackerone" form for reporting a vulnerability is the wrong
> form and the "My account has been hacked" form is also the wrong form. The
> whole site has been compromised, I have evidence and can't contact anyone
> due to the lack of an appropriate form and the fact that the security@
> email address doesn't work.
> >>
> >> Thanks!
> >
>
>

Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC

[Ross Tajvar]

Well yeah, people need to take responsibility, but IMO we as engineers need
to discuss the specific circumstances and methodologies that enable that to
happen. It's easy to say "they should fix it", and you're not wrong that
they should, but how? Do you have a validation framework in mind which
carriers can implement that prevents fraudulent caller ID information from
being sent without preventing legitimate use cases?

On Thu, Jul 11, 2019, 2:46 PM Keith Medcalf  wrote:

>
> On Thursday, 11 July, 2019 12:38, Ross Tajvar  wrote:
>
> >What if you use different carriers for termination and origination?
> >How does your termination carrier validate that your origination
> >carrier has allocated certain numbers to you and that you're
> >therefore allowed to make outbound calls with a caller ID set to
> >those numbers? That doesn't sound to me like something that can be
> >solved as quickly and easily as you imply.
>
> It does not really matter.  What matters is that they bear responsibility
> for an act in furtherance of a conspiracy to commit fraud.
>
> --
> The fact that there's a Highway to Hell but only a Stairway to Heaven says
> a lot about anticipated traffic volume.
>
>
> >
> >On Thu, Jul 11, 2019, 2:33 PM Keith Medcalf 
> >wrote:
> >
> >
> >
> >   On Thursday, 11 July, 2019 11:18, Christopher Morrow
> > wrote:
> >
> >   >On Thu, Jul 11, 2019 at 12:00 PM Paul Timmins
> > wrote:
> >
> >   >> Chris it would be trivial for this to be fixed, nearly
> >overnight,
> >   >> by creating some liability on the part of carriers for
> >illicit use of
> >   >> caller ID data on behalf of their customers.
> >
> >   >'illicit use of caller id' - how is caller-id being illicitly
> >used
> >   >though?
> >   >I don't think it's against the law to say a different
> >'callerid' in
> >   >the call session, practically every actual call center does
> >this, right?
> >
> >   The problem is that CallerID is not really the CallerID.  It is
> >some fraudulent shit created by the caller.  This is not how
> >"CallerID" was originally sold.  It was sold as being the ID of the
> >Caller.  If it is not the ID of the Caller then Fraud is being
> >committed and the bastards should be castrated (or worse), and the
> >CEO and Directors of the carrier responsible for fraud getting
> >through to the end-user should face the same penalty.
> >
> >   See then how quickly this gets fixed.  You will fall off your
> >chair and it will be a "solved problem" before your arse hits the
> >ground!
> >
> >   --
> >   The fact that there's a Highway to Hell but only a Stairway to
> >Heaven says a lot about anticipated traffic volume.
> >
> >
> >
> >
> >
>
>
>
>
>

Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC

[Ross Tajvar]

What if you use different carriers for termination and origination? How
does your termination carrier validate that your origination carrier has
allocated certain numbers to you and that you're therefore allowed to make
outbound calls with a caller ID set to those numbers? That doesn't sound to
me like something that can be solved as quickly and easily as you imply.

On Thu, Jul 11, 2019, 2:33 PM Keith Medcalf  wrote:

>
> On Thursday, 11 July, 2019 11:18, Christopher Morrow <
> morrowc.li...@gmail.com> wrote:
>
> >On Thu, Jul 11, 2019 at 12:00 PM Paul Timmins  wrote:
>
> >> Chris it would be trivial for this to be fixed, nearly overnight,
> >> by creating some liability on the part of carriers for illicit use of
> >> caller ID data on behalf of their customers.
>
> >'illicit use of caller id' - how is caller-id being illicitly used
> >though?
> >I don't think it's against the law to say a different 'callerid' in
> >the call session, practically every actual call center does this, right?
>
> The problem is that CallerID is not really the CallerID.  It is some
> fraudulent shit created by the caller.  This is not how "CallerID" was
> originally sold.  It was sold as being the ID of the Caller.  If it is not
> the ID of the Caller then Fraud is being committed and the bastards should
> be castrated (or worse), and the CEO and Directors of the carrier
> responsible for fraud getting through to the end-user should face the same
> penalty.
>
> See then how quickly this gets fixed.  You will fall off your chair and it
> will be a "solved problem" before your arse hits the ground!
>
> --
> The fact that there's a Highway to Hell but only a Stairway to Heaven says
> a lot about anticipated traffic volume.
>
>
>
>
>

Re: QoS for Office365

[Ross Tajvar]

I think the difficulty lies in appropriately marking the traffic. Like Joe
said, the IPs are always changing.

On Tue, Jul 9, 2019, 9:15 AM Mark Tinka  wrote:

>
>
> On 9/Jul/19 16:08, Joe Yabuki wrote:
> > Hi all,
> >
> > Thanks for your replies,
> >
> > I'll rephrase just to clarify, our aim is to do QoS within our
> > extended LAN (From remote sites to the Datacenter using the MPLS
> > provider as transit) - and we can't use DIA for a security reasons...
> >
> > So arguably, we still need to mark/queue/police packets at the Edge of
> > the Internet and on the remote site. For INTERNET we will throw
> > bandwidth so it will not be a point of congestion (hopefully once we
> > are in the Backbone's ISP we will go to Microsoft directly)
>
> In that case, co-ordinate the QoS profile with your MPLS provider and
> test both ends to make sure you receive what you send for on-net traffic.
>
> Verifying that your MPLS provider is forwarding your traffic according
> to the agreed-upon QoS profile is another thing.
>
> As for the off-net traffic entering your network, well, you know about
> that already...
>
> Mark.
>

Re: Intermittent "bad gateway"

[Ross Tajvar]

Gotta be more specific than that...

What carrier(s) are you using? If you do a traceroute do your packets take
a weird path? Etc.

On Tue, Jul 2, 2019, 10:19 AM Stephen Satchell  wrote:

> Are we having another BGP problem this morning?
>

Re: CloudFlare issues?

[Ross Tajvar]

On Mon, Jun 24, 2019 at 9:01 PM Jared Mauch  wrote:
>
> > On Jun 24, 2019, at 8:50 PM, Ross Tajvar  wrote:
> >
> > Maybe I'm in the minority here, but I have higher standards for a T1
than any of the other players involved. Clearly several entities failed to
do what they should have done, but Verizon is not a small or inexperienced
operation. Taking 8+ hours to respond to a critical operational problem is
what stood out to me as unacceptable.
>
> Are you talking about a press response or a technical one?  The impacts I
saw were for around 2h or so based on monitoring I’ve had up since 2007.
Not great but far from the worst as Tom mentioned.  I’ve seen people cease
to announce IP space we reclaimed from them for months (or years) because
of stale config.  I’ve also seen routes come back from the dead because
they were pinned to an interface that was down for 2 years but never fully
cleaned up.  (Then the telco looped the circuit, interface came up, route
in table, announced globally — bad day all around).
>

A technical one - see below from CF's blog post:
"It is unfortunate that while we tried both e-mail and phone calls to reach
out to Verizon, at the time of writing this article (over 8 hours after the
incident), we have not heard back from them, nor are we aware of them
taking action to resolve the issue."

> > And really - does it matter if the protection *was* there but something
broke it? I don't think it does. Ultimately, Verizon failed implement
correct protections on their network. And then failed to respond when it
became a problem.
>
> I think it does matter.  As I said in my other reply, people do things
like drop ACLs to debug.  Perhaps that’s unsafe, but it is something you do
to debug.  Not knowing what happened, I dunno.  It is also 2019 so I hold
networks to a higher standard than I did in 2009 or 1999.
>

Dropping an ACL is fine, but then you have to clean it up when you're done.
Your customers don't care that you *almost* didn't have an outage because
you *almost* did your job right. Yeah, there's a difference between not
following policy and not having a policy, but neither one is acceptable
behavior from a T1 imo. If it's that easy to cause an outage by not
following policy, then I argue that the policy should be better, or *something
*should be better - monitoring, automation, sanity checks. etc. There are
lots of ways to solve that problem. And in 2019 I really think there's no
excuse for a T1 not to be doing that kind of thing.

> - Jared

Re: CloudFlare issues?

[Ross Tajvar]

Maybe I'm in the minority here, but I have higher standards for a T1 than
any of the other players involved. Clearly several entities failed to do
what they should have done, but Verizon is not a small or inexperienced
operation. Taking 8+ hours to respond to a critical operational problem is
what stood out to me as unacceptable.

And really - does it matter if the protection *was* there but something
broke it? I don't think it does. Ultimately, Verizon failed implement
correct protections on their network. And then failed to respond when it
became a problem.

On Mon, Jun 24, 2019, 8:06 PM Tom Beecher  wrote:

> Disclaimer : I am a Verizon employee via the Yahoo acquisition. I do not
> work on 701.  My comments are my own opinions only.
>
> Respectfully, I believe Cloudflare’s public comments today have been a
> real disservice. This blog post, and your CEO on Twitter today, took every
> opportunity to say “DAMN THOSE MORONS AT 701!”. They’re not.
>
> You are 100% right that 701 should have had some sort of protection
> mechanism in place to prevent this. But do we know they didn’t? Do we know
> it was there and just setup wrong? Did another change at another time break
> what was there? I used 701 many  jobs ago and they absolutely had filtering
> in place; it saved my bacon when I screwed up once and started
> readvertising a full table from a 2nd provider. They smacked my session
> down an I got a nice call about it.
>
> You guys have repeatedly accused them of being dumb without even speaking
> to anyone yet from the sounds of it. Shouldn’t we be working on facts?
>
> Should they have been easier to reach once an issue was detected?
> Probably. They’re certainly not the first vendor to have a slow response
> time though. Seems like when an APAC carrier takes 18 hours to get back to
> us, we write it off as the cost of doing business.
>
> It also would have been nice, in my opinion, to take a harder stance on
> the BGP optimizer that generated he bogus routes, and the steel company
> that failed BGP 101 and just gladly reannounced one upstream to another.
> 701 is culpable for their mistakes, but there doesn’t seem like there is
> much appetite to shame the other contributors.
>
> You’re right to use this as a lever to push for proper filtering , RPKI,
> best practices. I’m 100% behind that. We can all be a hell of a lot better
> at what we do. This stuff happens more than it should, but less than it
> could.
>
> But this industry is one big ass glass house. What’s that thing about
> stones again?
>
> On Mon, Jun 24, 2019 at 18:06 Justin Paine via NANOG 
> wrote:
>
>> FYI for the group -- we just published this:
>> https://blog.cloudflare.com/how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-today/
>>
>>
>> _
>> *Justin Paine*
>> Director of Trust & Safety
>> PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D
>> 101 Townsend St., San Francisco, CA 94107
>> 
>>
>>
>>
>> On Mon, Jun 24, 2019 at 2:25 PM Mark Tinka  wrote:
>>
>>>
>>>
>>> On 24/Jun/19 18:09, Pavel Lunin wrote:
>>>
>>> >
>>> > Hehe, I haven't seen this text before. Can't agree more.
>>> >
>>> > Get your tie back on Job, nobody listened again.
>>> >
>>> > More seriously, I see no difference between prefix hijacking and the
>>> > so called bgp optimisation based on completely fake announces on
>>> > behalf of other people.
>>> >
>>> > If ever your upstream or any other party who your company pays money
>>> > to does this dirty thing, now it's just the right moment to go explain
>>> > them that you consider this dangerous for your business and are
>>> > looking for better partners among those who know how to run internet
>>> > without breaking it.
>>>
>>> We struggled with a number of networks using these over eBGP sessions
>>> they had with networks that shared their routing data with BGPmon. It
>>> sent off all sorts of alarms, and troubleshooting it was hard when a
>>> network thinks you are de-aggregating massively, and yet you know you
>>> aren't.
>>>
>>> Each case took nearly 3 weeks to figure out.
>>>
>>> BGP optimizers are the bane of my existence.
>>>
>>> Mark.
>>>
>>>

Re: Traffic ratio of an ISP

[Ross Tajvar]

I think that was a BitTorrent reference.

On Thu, Jun 20, 2019, 8:17 PM Valdis Klētnieks 
wrote:

> On Thu, 20 Jun 2019 10:16:03 -0600, "Keith Medcalf" said:
> > Having an inbound:outbound ration of 10:1 is known as a leech ...
>
> Just remember that without "leech" networks like Comcast, everybody who's
> selling transit to content providers would be having a hard sell
> indeed.
>
>

Re: Issue with point to point VPNs behind NAT and asymmetric traffic

[Ross Tajvar]

My guess is something is doing stateful filtering. If you send a SYN down
one link and the SYN-ACK comes back a different link, the receiving
firewall will discard it as bogus. You should be able to test this by doing
pcaps to confirm the traffic is arriving (though I'm not familiar with
WireGuard so maybe not), and you should be able to disable this by setting
a rule or unchecking a box in your firewall.

On Wed, Jun 12, 2019, 5:47 PM Anurag Bhatia  wrote:

> Hello everyone,
>
> Trying to get my head around a certain unexpected behaviour.
>
>
> I am running two site to site VPNs (wireguard now, OpenVPN earlier)
> between my home and a remote server over two different WAN links. Both WAN
> links are just consumer connections - one with public IP and one with
> CGNATed IP.
> The redundancy here is taken care of by the OSPF running via FRR on both
> ends.
>
>
> The unexpected behaviour I get is that if I set OSPF cost to prefer say
> link1 between home -> server and prefer link 2 between server -> home then
> connectivity completely breaks between the routed pools. The point to point
> IPs stay reachable (which is over expected links i.e symmetric via both
> ends). As long as both ends prefer link1 or link2, it works fine. At first,
> I thought it had to do something with NAT but still can't understand how.
> Since VPN tunnels have a keep-alive timer (for 10 seconds), the tunnel is
> always up. Any idea why asymmetric packets are being dropped here?
> This exact behaviour was in case of earlier OpenVPN + bird + iBGP and is
> still the same when I moved everything to Wireguard for VPN + FRR for
> routing + OSPF.
>
>
>
>
> Thanks.
>
>
> --
>
>
> Anurag Bhatia
> anuragbhatia.com
>

Re: someone is using my AS number

[Ross Tajvar]

Maybe try contacting the RIR?

On Wed, Jun 12, 2019, 12:23 PM Philip Lavine via NANOG 
wrote:

> yeah I did they are some MSP in India. No help.
>
> On Wednesday, June 12, 2019, 9:15:51 AM PDT, Filip Hruska 
> wrote:
>
>
> Contact the offending upstreams.
>
> Filip
>
> On 12 June 2019 6:05:58 pm GMT+02:00, Philip Lavine via NANOG <
> nanog@nanog.org> wrote:
>
> What is the procedure to have another party to cease and desist in using
> my AS number?
>
> Thx
>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>

Re: SSL VPN

[Ross Tajvar]

I've used that too. I found the admin interface to be pretty unintuitive.
And it kicks all active sessions without warning when you make a config
change.

On Sat, Jun 1, 2019, 2:32 PM Warren Kumari  wrote:

> OpenVPN AS?
>
> I’ve been running it for ~20 users for many years — it just works, has
> clients for many OSes, etc.
>
> W
>
> On Sat, Jun 1, 2019 at 10:54 AM Mehmet Akcin  wrote:
>
>> Hey there
>>
>> I am trying to choose SSL VPN for a remote office 3-4 people max each any
>> given time.
>>
>> I have looked at Pulse and Cisco, and wanted to check in here for
>> recommendations on latest trends.
>>
>> Trying to get a solution easy to manage and won’t break the bank with
>> licenses when team grows to 10.
>>
>> Thanks in advance.
>>
>> Mehmet
>> --
>> Mehmet
>> +1-424-298-1903
>>
> --
> I don't think the execution is relevant when it was obviously a bad idea
> in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair of
> pants.
>---maf
>

Re: [nanog] Re: SSL VPN

[Ross Tajvar]

I've used Pulse and AnyConnect (as a user) and Windows-based SSTP (as an
admin). They all worked well. The nice part about the Windows option is
that it's cheap (you only need to pay for a Windows license).

On Sat, Jun 1, 2019, 12:53 PM Hansen, Christoffer 
wrote:

> A solution based upon SSTP?
>
> Have used SSTP on Mikrotik gear in the past. Works well once setup is done.
> https://wiki.mikrotik.com/wiki/Manual:Interface/SSTP
>
> *Windows do e.g. have built-in support for SSTP based VPN solutions.
>
> Christoffer
>

Re: Google weird routing?

[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  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 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: BGP prefix filter list

[Ross Tajvar]

In that case shouldn't each company advertise a /21?

On Wed, May 22, 2019, 1:11 PM Sabri Berisha  wrote:

> Hi,
>
> One legitimate reason is the split of companies. In some cases, IP space
> needs to be divided up. For example, company A splits up in AA and AB, and
> has a /20. Company AA may advertise the /20, while the new AB may advertise
> the top or bottom /21. I know of at least one worldwide e-commerce company
> that is in that situation.
>
> Thanks,
>
> Sabri
>
>
> - On May 22, 2019, at 9:40 AM, Tom Beecher  wrote:
>
> There are sometimes legitimate reasons to have a covering aggregate with
> some more specific announcements. Certainly there's a lot of cleanup that
> many should do in this area, but it might not be the best approach to this
> issue.
>
> On Tue, May 21, 2019 at 5:30 AM Alejandro Acosta <
> alejandroacostaal...@gmail.com> wrote:
>
>>
>> On 5/20/19 7:26 PM, John Kristoff wrote:
>> > On Mon, 20 May 2019 23:09:02 +
>> > Seth Mattinen  wrote:
>> >
>> >> A good start would be killing any /24 announcement where a covering
>> >> aggregate exists.
>> > I wouldn't do this as a general rule.  If an attacker knows networks are
>> > 1) not pointing default, 2) dropping /24's, 3) not validating the
>> > aggregates, and 4) no actual legitimate aggregate exists, (all
>> > reasonable assumptions so far for many /24's), then they have a pretty
>> > good opportunity to capture that traffic.
>>
>>
>> +1 John
>>
>> Seth approach could be an option _only_ if prefix has an aggregate
>> exists && as origin are the same
>>
>>
>> > John
>>
>
>

Re: DHCPv6-PD relay route injection - standard?

[Ross Tajvar]

On Fri, May 17, 2019 at 2:44 PM Tim Howe  wrote:

> Getting native dual-stack fully working
> has been a long, strange road as a small ISP.  I'm thinking about
> writing something up about my experience so far.
>


I would definitely read that.

Re: BGP prefix filter list

[Ross Tajvar]

If you're going whitebox, I would check out Netgate's new product called
TNSR. It uses VPP for the data plane, which does all its processing in user
space, thus avoiding the inefficiencies of the kernel network stack. That's
particularly important at higher speeds like 40G or 100G.

Disclaimer: I have not tried it myself but I've only heard good things.

On Wed, May 15, 2019 at 12:01 PM Brielle Bruns  wrote:

> On 5/15/2019 9:46 AM, Hansen, Christoffer wrote:
> >
> >> 'Tik, white box Linux/BSD, etc all offer good options at varying price
> >> points.
> >
> > Any pointers and/or references, when looking into speeds *above* what is
> > possible with aggregated 10G links?
> >
>
>
> That's a good question - I've not gotten past 10G yet.
>
> Cheaply, you could get ConnectX-3 40G PCIe cards and throw them in your
> favorite Dell/HP/Supermicro/other rack mount server with your Linux/BSD
> distro of choice, or VyOS for that matter.
>
> There are instructions online on converting the IB versions of the
> Mellanox cards to their Ethernet counterparts, if you want to cut some
> cost even more.
>
> --
> Brielle Bruns
> The Summit Open Source Development Group
> http://www.sosdg.org/ http://www.ahbl.org
>

Re: historical BGP announcements? (pre-1997)

[Ross Tajvar]

Hey John,

Just out of curiosity, what do you need this data for?

On Mon, May 6, 2019, 3:53 PM Bill Woodcock  wrote:

>
>
> > On May 6, 2019, at 12:47 PM, John Osmon  wrote:
> >
> > I've got a need to look for some announcements from the mid 1990s.
> > The oldest I've found at at the University of Oregon Route Views
> > Project, but the earliest I can find there appears to be November of
> > 1997.
>
> That’s when PCH began archiving them (and subsequently turned that archive
> over to U of O).  We weren’t aware of anyone publicly archiving transit
> routes prior to that.
>
> -Bill
>
>

Re: Disney+ CDN

[Ross Tajvar]

Agreed, I noticed the single IX as well and asked them about it in my
email. If they don't expand aggressively in the next ~6 months, they're
going to have a very problematic launch.

On Fri, Apr 26, 2019 at 5:59 PM Jon Lewis  wrote:

> On Fri, 26 Apr 2019, Ross Tajvar wrote:
>
> > Yeah, I'm going to send them an email and see if I can get ahold of
> their peering policy.
> > I'm hoping they will update it as they get more attention from other
> networks. They may just be procrastinating
> > setting things up. According to bgp.he.net they are only announcing one
> v4 /24 and one v6 /48, which could be
> > enough IPs, but seems a little on the small side.
>
> I'd be much more worried about only being on one IX than only advertising
> a single /24 and /48.  I'm guessing they've just not fully fleshed out the
> peeringdb entry and maybe not fully built out the network infrastructure
> yet.  A CDN, with everything coming from one POP in NY is not going to cut
> it.
>
> --
>   Jon Lewis, MCP :)   |  I route
>   |  therefore you are
> _ http://www.lewis.org/~jlewis/pgp for PGP public key_
>

Re: Disney+ CDN

[Ross Tajvar]

Sorry for the double email but I wanted to add - the ARIN org was only
created in November 2018:

OrgName:Disney Streaming Services
OrgId:  DSTL-2
Address:75 9th Ave.
Address:6th Floor
City:   New York
StateProv:  NY
PostalCode: 10011
Country:US
RegDate:2018-11-15
Updated:2018-11-15
Ref:https://rdap.arin.net/registry/entity/DSTL-2


On Fri, Apr 26, 2019 at 5:41 PM Ross Tajvar  wrote:

> Yeah, I'm going to send them an email and see if I can get ahold of their
> peering policy.
>
> I'm hoping they will update it as they get more attention from other
> networks. They may just be procrastinating setting things up. According to
> bgp.he.net they are only announcing one v4 /24 and one v6 /48, which
> *could* be enough IPs, but seems a little on the small side.
>
> On Fri, Apr 26, 2019 at 5:37 PM Bryan Holloway  wrote:
>
>>
>>
>> On 4/26/19 4:33 PM, Ross Tajvar wrote:
>> > Looks like Disney has an ASN for their streaming service:
>> > https://www.peeringdb.com/net/15627
>> >
>>
>> Helluva entry ...
>>
>> *crickets*
>> *tumbleweeds*
>>
>

Re: Disney+ CDN

[Ross Tajvar]

Yeah, I'm going to send them an email and see if I can get ahold of their
peering policy.

I'm hoping they will update it as they get more attention from other
networks. They may just be procrastinating setting things up. According to
bgp.he.net they are only announcing one v4 /24 and one v6 /48, which *could* be
enough IPs, but seems a little on the small side.

On Fri, Apr 26, 2019 at 5:37 PM Bryan Holloway  wrote:

>
>
> On 4/26/19 4:33 PM, Ross Tajvar wrote:
> > Looks like Disney has an ASN for their streaming service:
> > https://www.peeringdb.com/net/15627
> >
>
> Helluva entry ...
>
> *crickets*
> *tumbleweeds*
>

Re: Disney+ CDN

[Ross Tajvar]

Looks like Disney has an ASN for their streaming service:
https://www.peeringdb.com/net/15627

On Fri, Apr 26, 2019 at 5:26 PM Bryan Holloway  wrote:

>
> On 4/12/19 2:31 PM, Chris Grundemann wrote:
> >
> >
> >
> > On Fri, Apr 12, 2019 at 3:03 PM Jared Geiger  > > wrote:
> >
> > An article mentioned BAMTech's platform which is what NHL, MLB, and
> > HBO GO are built on. The bits from the first two come from Akamai
> > and Level3 CDNs. I haven't looked into where HBO Go comes from.
> >
> >
> > Yep, they decided to buy BAMTech and build their own:
> >
> https://www.thewaltdisneycompany.com/walt-disney-company-acquire-majority-ownership-bamtech/
> >
>
> So, on a practical level, with whom should I peer so as not to jack up
> my transit costs?
>
>

Re: My .sig (Was Re: Packetstream - how does this not violate just about every provider's ToS?)

[Ross Tajvar]

I want to clarify that while I didn't say anything (since it wasn't
on-topic in the other thread), I also found the long signature annoying. I
did not read it beyond the first 1-2 lines. I expect many more than the few
people who spoke up share this opinion.

While I don't feel it's appropriate for people to complain about something
so trivial as an email signature in a pseudo-professional
setting, apparently we're doing it today.

I don't like email signatures in general, but since you asked for
suggestions, I suggest using your name and one title that seems most
relevant/important.

On another note: I don't think you need credentials to be taken seriously
here as long as you present a respectful and coherent argument. I would not
have questioned your background if you had posted this without credentials,
or if anyone else had posted it. I don't recognize the names of most of the
"top talkers" or know their credentials, other than my assumption that they
are network operators of some sort.

I'm sorry that you've had negative experiences re: your background.
Ultimately, it is up to each individual whether they choose to respect
others and for what reasons. There is little we can do to influence that.

On Fri, Apr 26, 2019 at 5:01 PM Anne P. Mitchell, Esq. 
wrote:

> Oops..sorry to follow up on myself (and before anybody says anything about
> this, sorry/not sorry for top-posting - it's on myself after all)..but I'd
> meant to include this:
>
>
> Case in point:  This very (original) thread, about Packetstream - if I had
> just posted the original thread, about how it's inducing users to violate
> their providers' ToS, how that's a breach of contract, etc... how many here
> would have a) not given a second thought, writing it off as the rantings of
> at best someone who doesn't know anything, and at worst a troll, or b)
> would have challenged me to explain my credentials - which would have take
> up far more space than my .sig :-(
>
> Anne
>
> > On Apr 26, 2019, at 2:55 PM, Anne P. Mitchell, Esq. 
> wrote:
> >
> > Apparently, after many, many years of using essentially the same .sig
> here, it is now an issue of contention.  (Well, 3 people probably does not
> contention make, but still...).
> >
> > However, as one person decided I was trying to market myself, let me
> address why I have all of that info in there:
> >
> > Primarily I leave in all of my background because people (at least those
> here in the states) tend to a) assume that attorneys are all just
> "corporate suits" with no understanding of or experience with deep Internet
> issues, and b) attorneys are generally disliked. ;-)  Over the years I've
> found that it's best to include my chops right up front, so folks can be
> reassured that I'm not only on the right (white hat) side of things, but
> that I actually do know what I'm talking about.
> >
> > I can tell you absolutely that the pushback I get from people in our
> industries who *don't* know my background, when I provide information based
> on that background and my expertise, is far greater, and bordering at times
> on abusive (come to think of it, not unlike some of the pushback I got when
> I first arrived at MAPS, from a certain volunteer  ;-)).
> >
> > I'm open to suggestions (other than the suggestion to sod off).
> >
> > Anne
> >
> > [This .sig space open to suggestions.]
> >
>
>

Re: Ownership of Routers on Both Ends of Transnational Links

[Ross Tajvar]

I think it's clear that the IPs belong to Telia, but I understood James's
point to be that the router using the IP in question may belong to China
Unicom. (I agree with that, I was not thinking clearly this morning.) As
this is an interconnect link, one side must belong to Telia and the other
to China Unicom. The question, then, is which side are we looking at? Well,
first I want to know how big the subnet is. I assume either /30 or /31. So,
I do a reverse DNS lookup on all the IPs in the surrounding /30 block:
62.115.170.56 - sjo-b21-link.telia.net
62.115.170.57 - chinaunicom-ic-341501-sjo-b21.c.telia.net
62.115.170.58 - las-b24-link.telia.net
62.115.170.59 - chinaunicom-ic-341499-las-b24.c.telia.net
That looks like two /31s. Only one IP in each has the name of China Unicom
in it, so that one is probably in use by China Unicom, and the other is
probably in use by Telia.

On Tue, Apr 16, 2019, 3:50 PM Christopher Morrow 
wrote:

> On Tue, Apr 16, 2019 at 10:59 AM James Jun  wrote:
>
> > More likely, thease routers are China Unicom's routers in their US POP,
> not managed by VZ/Telia.
> > The /30s in this case are unmanaged IP transit hand-offs, coming in as
> Nx10G or 100G.  When your
> > IP transit provider assigns the /30, your router looks like it belongs
> to your upstream, common
> > mistake when interpreting traceroutes[1].
> >
>
> $ nslookup 62.115.170.56
> 56.170.115.62.in-addr.arpa name = sjo-b21-link.telia.net.
>
> if you model (as james says) each interconnect as a /30 or /31 ...
> look for the adjacent ip and see the PTR for that ip.
> (the above is your first link example's peer ip)
>
> > [1]: see Page 22 on
> https://www.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_N47_Sun.pdf
> >
> > James
>

Re: Ownership of Routers on Both Ends of Transnational Links

[Ross Tajvar]

"company-ic" and "company-gw" are commonly used names for /30s used for
interconnection to a customer or another carrier. Those routers are likely
owned/managed by Telia/Verizon.

On Tue, Apr 16, 2019 at 8:54 AM Pengxiong Zhu  wrote:

> Howdy folks,
>
> We are a group of researchers at UC Riverside conducting some measurement
> about transnational networks. In particular, we are interested in studying
> the ownership of routers on the two sides of transnational links.
>
> We have some concrete questions which we hope someone can shed some light
> on. Basically when we send packets from US/Canada to China, through
> traceroute and the RTT of each hop, we can locate the last hop in the US
> before the packets enter China (*there is a large jump of RTT of 100+ms
> from this hop onwards*). Oftentimes the ownership of such routers is
> ambiguous.
>
> These hops whose IPs seem to belong to US or European ISPs (*according to
> BGP info*) but their reverse DNS names have *chinaunicom* in it, which is
> a Chinese ISP.
> AS1299 Telia Company AB
> 62.115.170.57name = chinaunicom-ic-341501-sjo-b21.c.telia.net.
> 62.115.33.230name = chinaunicom-ic-302366-las-bb1.c.telia.net.
> 213.248.73.190  name = chinaunicom-ic-127288-sjo-b21.c.telia.net.
>
> AS701 Verizon Business
> 152.179.103.254  name = chinaunicom-gw.customer.alter.net.
>
> While the following routers, they don't have a reverse DNS name at all,
> which seem to be uncommon if they were managed by US or European ISPs but
> quite common for Chinese ISPs.
> AS6453 TATA COMMUNICATIONS (AMERICA) INC
> 63.243.205.90
> 66.110.59.118
>
> Can anyone confirm that these are indeed managed by the Chinese ISPs (even
> though they are physically located in the US according to the traceroute
> and RTT analysis)?
>
>
> Best,
> Pengxiong Zhu
> Department of Computer Science and Engineering
> University of California, Riverside
>

Re: Gi Firewall for mobile subscribers

[Ross Tajvar]

I agree with Owen that an always-on firewall which blocks all inbound
traffic would be very frustrating to some users. I do understand your need
as a provider to prevent expensive signaling operations. I think the
suggestion of a toggle in a web portal to disable the firewall is a good
compromise. Most users will not need to make inbound connections to their
cellular devices, so the impact to your network would likely be small.

On Wed, Apr 10, 2019 at 4:23 PM Amos Rosenboim  wrote:

> Owen,
>
> Let me clarify a few points:
>
> 1. I am in favor of end to end connectivity and IPv6 can help restore this.
>
> 2. In the fixed broadband portion of the network this is the case.
> IPv6 is routed to the subscriber CPE.
> Firewall on the CPE is turned on by default, but can be turned off by the
> user.
>
> 3. In the mobile portion life are a bit more complicated.
> Unsolicited traffic from the internet towards an idle subscriber triggers
> a signaling process called paging.
> Extra paging is expensive in terms of signaling resource utilization, as
> well as on device battery.
>
>
> Amos
>
> Sent from my iPhone
>
> On 10 Apr 2019, at 22:52, Owen DeLong  wrote:
>
>
> We have an ongoing discussion about Gi firewall (adding a firewall between
>> the subscribers and the internet, allowing only subscriber initiated
>> connections), for the IPv6 traffic.
>>
>
>>
>> The firewall is doing very little security, the ruleset is very basic,
>> allowing anything from subscribers to the internet and blocking all traffic
>> from the internet towards the subscribers.
>>
>> We have a few rules to limit the number of connections per subscriber (to
>> a relatively high number) and that is it.
>>
>
> What would be the process for a subscriber who wishes to allow inbound
> connections?
>
> If you are simply saying that as a customer of your ISP you simply can’t
> allow inbound IPv6 connections at all, then you are becoming a very poor
> substitute for an ISP IMHO.
>
>  One of the arguments in favor of having the firewall is that unsolicited
>> traffic from the internet can “wake” idle mobile devices, and create
>> signaling (paging) storms as well as drain user batteries.
>>
>>
> There are lots of ways to configure alerts and reduce this problem space.
> If you want to provide a checkbox on the my.t-mobile page for the user to
> turn this firewall on or off on a per device basis, then sure, I could see
> that as viable. Even if it annoyingly defaults to on.
>
>
> On the other hand, allowing only subscriber initiated traffic is mostly
>> achievable using ACLs on the mobile core facing routers, or is it with the
>> growing percentage of UDP traffic ?
>>
> Is it even desirable to allow only subscriber initiated traffic?
>
> Case in point, I will occasionally end up tethering my laptop (mobile hot
> spot) and want certain authorized individuals to be able to VNC into it via
> that tethering connection.
>
> There have been other times when I’ve had things on the other side of a
> tether that I wanted to ssh into.
>
> There are also things like Particle IONs where it is desirable to be able
> to push firmware updates OTA. I realize that Particle is sadly lagging on
> IPv6 support, but it will, hopefully, one day become a valid use case as
> well.
>
> BTW – I don’t mention IPv4 traffic on the mobile network as it’s all
>> behind CGNAT which don’t allow internet initiated connections.
>>
> Yes, but IPv6 is supposed to hope us recover from this travesty.
>
> Anyway, we are very interested to know hear more opinions,  and especially
>> to hear what are other mobile operators do.
>>
>
> As is tradition, most operators screw the customer in one way or another
> in this regard. Some haven’t thought about screwing customers in this
> particular way in IPv6 yet and so IPv6 sometimes works as one would hope.
>
> Owen
>
>
>

Re: Amazon AS16509 peering... how long to wait?

[Ross Tajvar]

>From what I've heard, their peering department is really behind on
processing new peer turn-ups.

On Sun, Apr 7, 2019, 6:16 PM Mehmet Akcin  wrote:

> I will connect you to right people offlist
>
> I am surprised its taking that long
>
> On Sun, Apr 7, 2019 at 16:41 John Von Essen  wrote:
>
>> I applied for peering, received an email, setup the BGP session, waited
>> about a month. Then 3 weeks ago my BGP session with Amazom came up, but
>> with zero routes. I assume I am in some kind of test/waiting period, but
>> after three weeks, I thought I would be getting routes by now. Emails to
>> the peeringdb POC have not returned anything. Anyone here from AS16509,
>> can this be bumped? We are AS17185, and peering is on DE-CIX NYC.
>>
>>
>> Thanks
>>
>> John
>>
>> --
> Mehmet
> +1-424-298-1903
>

Re: residential/smb internet access in 2019 - help?

[Ross Tajvar]

On Wed, Mar 27, 2019, 12:30 AM Mike Bolitho  wrote:

> Agreedthis is why monopolies are bad and municipal fiber is good.
>>
>
> It's not like municipal fiber has some magic spell to make last mile
> affordable though. On OP's instance he would run into the same issue and
> would be paying that five figure amount to bring FTTP. Municipal fiber is
> only good if you happen to live where a municipality has already buried
> conduit.
>
> I'm not saying we should support monopolistic practices, but "municipal
> fiber everywhere!" isn't necessarily the answer either.
>

That's fair. What I really meant, and didn't take the time to think through
and express properly, was this: financing a large fiber buildout like it's
a long-term investment, rather than something that should make back its
capital cost in 1-3 years, gets fiber to more people. Most commercial ISPs
do not want to do this because they want immediate profit. Municipalities
are used to making long-term infrastructure investments (like bridges,
etc.) and are more amenable to doing it with fiber.

Even if there were a municipality which had done a fiber buildout near OP's
desired house, he may have still run into the same issue of no fiber being
close enough to be financially viable. But the more fiber plant there is,
the less likely that scenario becomes.

>

Re: residential/smb internet access in 2019 - help?

[Ross Tajvar]

On Tue, Mar 26, 2019, 11:34 PM david raistrick  wrote:

> On Tue, Mar 26, 2019 at 11:29 PM Ross Tajvar  wrote:
>
>
>> But most likely you're just out of luck.
>>
>
> it's really amazing that this is still the case, with our effectively
> internet based economy now.
>
>

Agreedthis is why monopolies are bad and municipal fiber is good.

>