WhatsApp a bit flakey

[Dovid Bender]

FYI: It seems there are global issues with WhatsApp. Calls do not seem to
be working and messaging is sporadic up and down.

Re: All crickets at HE

[Dovid Bender]

Try supp...@he.net. You can also always try 510-580-4100 which usually gets
picked up really quickly.


On Sun, Mar 24, 2024 at 11:59 PM Pascal Masha  wrote:

> Seems like the good folks at noc@he are no longer responding to emails!!
> Is anyone else on the list experiencing this?
>
> Regards,
> Paschal Masha
>

Re: cogent - Sales practices

[Dovid Bender]

It's not just you. I saw a social media post with the exact format posted
by someone who got a similar email.

On Fri, Aug 5, 2022, 16:20 Dennis Burgess  wrote:

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

Re: Scanning the Internet for Vulnerabilities

[Dovid Bender]

On Sun, Jun 19, 2022 at 8:01 AM Ronald F. Guilmette 
wrote:

> In message  udtn6t1o+cv-nh6jbz...@mail.gmail.com>
> Dovid Bender 
> >I know that in Israel the cyber dept of the government scans IL IP space
> >then notifies ISP's to notify their clients. This helps where you have
> >clueless people that don't know they have devices that can easily be
> >compromised.
>
> That's most interesting and I certainly did not know that.
>
> Do you have confidence that such scanning is limited to Israeli IP
> addresses?
>
> Not at all. I think it's obvious that every nation state "pokes around"
the internet.

> Are there any private firms that you are aware of in Israel that engage in
> such scanning also?
>
I don't know who is doing it. I just know that IL Cert contacted our parent
company which has an ISP in Israel when things were "hot".

Re: Scanning the Internet for Vulnerabilities

[Dovid Bender]

I know that in Israel the cyber dept of the government scans IL IP space
then notifies ISP's to notify their clients. This helps where you have
clueless people that don't know they have devices that can easily be
compromised.


On Sun, Jun 19, 2022 at 6:13 AM Ronald F. Guilmette 
wrote:

> I would like to solicit the opinions of network operators on the practice
> of scanning all of, or large chunks of the internet for known
> vulnerabilities.
>
> In earlier times, this was generally viewed as being distinctly anti-social
> behavior, but perhaps attitudes have changed relative to earlier eras.
> I would thus like to know how people feel about it now, in 2022.
>
>
> Regards,
> rfg
>
>
> P.S.  Just to be clear, I personally have neither any desire nor any intent
> to undertake such activity myself, nor am I in communiacation with any
> party
> or parties that have such an intent or desire.  I cannot however say that I
> am unaware of any parties that may currently be involved in such
> activities.
>

Re: Starlink terminals deployed in Ukraine

[Dovid Bender]

>From a quick google search it seems to be 14593.


On Mon, Feb 28, 2022 at 11:48 PM Ong Beng Hui  wrote:

> Curious, will that be with starlink ASN then ?
>
> That throw geo detection via IP out right away.
>
> On 3/1/2022 6:55 AM, Jay Hennigan wrote:
> >
> https://www.cnbc.com/2022/02/28/ukraine-updates-starlink-satellite-dishes.html
> >
> >
>

Re: BANDWIDTH and VONAGE lose FCC rules exemption for STIR/SHAKEN

[Dovid Bender]

On Fri, Feb 18, 2022 at 2:33 PM Michael Thomas  wrote:

>
> On 2/17/22 11:58 AM, Sean Donelan wrote:
> >
> >
> https://www.fcc.gov/document/fcc-finds-two-providers-failed-fully-implement-stirshaken-0
> >
> >
> > The Federal Communications Commission today took action to ensure that
> > voice service providers meet their commitments and obligations to
> > implement STIR/SHAKEN standards to combat spoofed robocall scams.
> > Specifically, voice service providers Bandwidth and Vonage lost a
> > partial exemption from STIR/SHAKEN because they failed to meet
> > STIR/SHAKEN implementation commitments and have been referred to the
> > FCC’s Enforcement Bureau for further investigation.
>
>
> So for probably a year or so before the Stir/Shaken mandate came, I have
> been seeing a lot less phone spam. I don't know if that's typical but it
> was quite noticeable for me. What that tells me is that providers likely
> started clamping down on their shady customers well ahead of the mandate
> which says that regulatory fiat would have been sufficient too. But that
> hinges on whether my situation is typical though.
>
> Mike
>
We have seen an uptick in requests for routes to Canada and the UK from
Proton email accounts... We ask for business documents and never hear back.

Re: DOJ files suit to enforce FCC penalty for robocalls

[Dovid Bender]

We have telco's registered in the US, Cyprus and Israel. Lately I'm Europe
we have been getting emails from people using protonmail. The conversation
dies one we ask for business registration documents.

On Thu, Oct 21, 2021, 16:14 Aaron C. de Bruyn via NANOG 
wrote:

> My normal test for this is to register a new domain name and leave my
> whois info public.
>
> Over the span of 1-2 weeks I will usually get 50-100 calls from people
> with a certain accent asking for a  mispronunciation of my name and if I
> need a website developed.  Then I forward them over to my spam recording
> line.
>
> I registered a handful of new domains this week, and I've had less than 5
> calls so far.
>
> -A
>
>
> On Thu, Oct 21, 2021 at 12:13 PM Michael Thomas  wrote:
>
>>
>> On 10/21/21 10:57 AM, Sean Donelan wrote:
>> >
>> > The multi-million dollar fines announced with great fanfaire by the
>> > Federal Communication Commission are almost never collected. The FCC
>> > doesn't have enforcement authority to collect fines. The FCC usually
>> > withholds license renewals until penalties are paid. If the violator
>> > doesn't have any FCC licenses (or doesn't care), the FCC is powerless.
>> >
>> > The FCC refers uncollected penalties to the Department of Justice. In
>> > the past, DOJ didn't prioritize uncollected penalties and most fines
>> > were never enforced.
>> >
>> >
>> > The Department of Justice Files Suit to Recover $9.9 Million
>> > Forfeiture Penalty for Nearly 5,000 Illegally Spoofed Robocalls
>> >
>> >
>> https://www.justice.gov/opa/pr/department-justice-files-suit-recover-forfeiture-penalty-nearly-5000-illegally-spoofed
>> >
>>
>> So has any of the STIR/SHAKEN stuff that was mandated made any
>> difference on the ground yet? I assume this is different than what you
>> posted about though.
>>
>> Mike
>>
>>

Re: Xfi Advances Security (comcast)

[Dovid Bender]

Could it be related to the many FortiNet devices being exploited? About 45k
credentials were dumped two days ago. Many are still working.


On Fri, Sep 10, 2021 at 10:56 AM Chris Boyd  wrote:

>
>
> > On Sep 10, 2021, at 9:31 AM, Jason Kuehl 
> wrote:
> >
> > For whatever reason Comcast Xfinity is blocking my VPN URL. I've started
> the process to unblock, and I'm trying to get a hold of their security team
> to resolve this. I've been bounced around all morning.
> >
> > Does anyone have a contact at Comcast that can whitelist a URL or get me
> to a team that can understand what is going on for the block to happen?
>
> Why is Comcast blocking things? That seems like it’s out of scope for an
> ISP.
>
> —Chris

Re: OOB management options @ 60 Hudson & 1 Summer

[Dovid Bender]

We use Raritan console devices in NJR2 and I couldn't be happier. They
allow you to have to connections. We have a VPN device that is connected to
our wan switches and then we have Verizon LTE as a backup. When we first
went with T-Mobile we had problems with the connectivity (see
https://mailman.nanog.org/pipermail/nanog/2019-January/098723.html). We
then moved over to Verizon where the signal was strong but we had issues
with the MTU issues (see
https://mailman.nanog.org/pipermail/nanog/2019-June/101576.html). I ended
up adding a rule to the raritan to lower the PDU and that allowed
connectivity via the cellular network. I used the cellular modem that
raritan recommended although I probably could have gone with something
cheaper like the MikroTik LtAP.



On Thu, Apr 15, 2021 at 6:14 PM Matthew Crocker 
wrote:

>
>
> I have routers in both 60 Hudson St & 1 Summer St and I’m looking for some
> low cost bandwidth options for out of band management.  Currently I have
> Opengear boxes at each site with cell modems but they don’t work too well.
> I either need to replace them with new cell based devices or find a
> wireless/ethernet bandwidth option.   I only need a couple serial ports and
> ethernet for when everything breaks.
>
>
>
> I’m in DR space @ 60 Hudson and the Markeley MMR @ 1 Summer
>
>
>
> I’m surprised OOB bandwidth isn’t a feature for colocation providers.
>
>
>
> Thanks
>
>
>

Re: Famous operational issues

[Dovid Bender]

On Mon, Feb 22, 2021 at 2:05 PM Warren Kumari  wrote:

>
>
> On Mon, Feb 22, 2021 at 12:50 PM Regis M. Donovan 
> wrote:
>
>> On Thu, Feb 18, 2021 at 07:34:39PM -0500, Patrick W. Gilmore wrote:
>> > And to put it on topic, cover your EPOs
>>
>> I worked somewhere with an uncovered EPO, which was okay until we had a
>> telco tech in who was used to a different data center where a similar
>> looking button controlled the door access, so he reflexively hit it
>> on his way out to unlock the door.  Oops.
>>
>> Also, consider what's on generator and what's not.  I worked in a
>> corporate
>> data center where we lost power.  The backup system kept all the machines
>> running, but the ventilation system was still down, so it was very warm
>> very
>> fast as everyone went around trying to shut servers down gracefully while
>> other folks propped the doors open to get some cooler air in.
>>
>
> That reminds me of another one...
>
> In parts of NYC, there are noise abatement requirements, and so many
> places have their generators mounted on the roof -- it's cheap real-estate,
> the exhaust is easier, the noise issues are less, etc.
>
> The generators usually have a smallish diesel tank, and then a much larger
> one in the basement (diesel is heavy)...
>
> So, one of the buildings that I was in was really good about testing thier
> gensets - they'd do weekly tests (usually at night), and the generators
> always worked perfectly -- right up until the time that it was actually
> needed.
> The generator fired up, the lights kept blinking, the disks kept spinning
> - but the transfer pump that pumped diesel from the basement to the roof
> was one of the few things that was not on the generator
>
>
When we were looking at one of the big carrier hotels in NYC  they said
that they had the same issue (could be it was the same one). The elevators
were also out as well. They resorted to having techs climb up an down 9
flights of stairs all day long with 5 gallon buckets of diesel and throwing
it into the generator.

>

Re: Viable Third Option?

[Dovid Bender]

Second for NTT. We have found that their pricing wasn’t to far off from HE.
I can count on one hand in 10 years how many times we had issues and needed
to contact them.

On Wed, Feb 17, 2021 at 14:06 David Hubbard 
wrote:

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

Re: AT - INET Data Caps

[Dovid Bender]

We have employees using Comcast at home and they have a max of 1TB per
month. They are now going after clients forcing them to update to an
unlimited plan or pay per GB over 1TGB.


On Mon, Nov 30, 2020 at 1:05 PM Paul Emmons  wrote:

> Yes this is common business practice for almost all of the MSOs.
>
> On Mon, Nov 30, 2020 at 9:45 AM Thomas Yarger 
> wrote:
>
>> Hello All,
>>
>> This past week when I was helping my father perform some home networking,
>> I called AT to get a newer Arris router and they mentioned that if I were
>> to upgrade his service, he would fall under a 1 TB data cap for home
>> internet. Is this just in FL or have others seen similar restrictions with
>> AT? Thanks!
>>
>> --
>> Thanks,
>>
>> Thomas Yarger
>>
>>

Re: CNAME records in place of A records

[Dovid Bender]

Interesting. We got a few requests at the same time which is what made we
wonder. I wanted to make sure that there wasn't something I was missing.


On Fri, Nov 6, 2020 at 5:25 AM Ray Orsini  wrote:

> It's not a security thing. We do this with the the resellers who white
> label our VOIP. CNAMEs allow us to be flexible with our own hosts and
> infrastructure without having all of our resellers change DNS records.
> [image: OIT Website] <https://www.oit.co/>
> Ray Orsini​
> Chief Executive Officer
> OIT, LLC
>  *305.967.6756 x1009* <305.967.6756%20x1009>  |   *305.571.6272*
>  *r...@oit.co*   |  [image: https://www.oit.co]
> <https://www.oit.co/> * www.oit.co* <https://www.oit.co/>
>  oit.co/ray
> [image: Facebook] <https://go.oit.co/facebook>
> [image: LinkedIn] <https://go.oit.co/linkedin>
> [image: Twitter] <https://go.oit.co/twitter>
> [image: YouTube] <https://go.oit.co/youtube>
>
> *How are we doing? We'd love to hear your feedback. https://go.oit.co/review*
> <https://zoom.us/webinar/register/2015851001337/WN_otbRE8XZSVOitAPS_qZ9Zg>
> --
> *From:* NANOG  on behalf of Dovid
> Bender 
> *Sent:* Friday, November 6, 2020 5:07:26 AM
> *To:* NANOG 
> *Subject:* CNAME records in place of A records
>
> Hi,
>
> Sorry if this is a bit OT. Recently several different vendors (in
> completely different fields) where they white label for us asked us to
> remove A records that we have going to them and replace them with CNAME
> records. Is there anything *going around* in the security aranea  that has
> caused this?
>

CNAME records in place of A records

[Dovid Bender]

Hi,

Sorry if this is a bit OT. Recently several different vendors (in
completely different fields) where they white label for us asked us to
remove A records that we have going to them and replace them with CNAME
records. Is there anything *going around* in the security aranea  that has
caused this?

Re: Microsoft is hacking my Asterisk??? O_o

[Dovid Bender]

we have seen 8.8.8.8 end up on some ban lists.


On Tue, Nov 3, 2020 at 3:17 PM Mike Hammett  wrote:

> Ah, so then potentially spoofed, trying to get people to honeypot
> blacklist XBox.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions 
> 
> 
> 
> 
> Midwest Internet Exchange 
> 
> 
> 
> The Brothers WISP 
> 
> 
> --
> *From: *"Josh Luthman" 
> *To: *"Mike Hammett" 
> *Cc: *"Max Tulyev" , "NANOG list" 
> *Sent: *Tuesday, November 3, 2020 2:03:01 PM
> *Subject: *Re: Microsoft is hacking my Asterisk??? O_o
>
> I've seen that, a shared IP on Azure that hit my honeypot IP.  Ended up
> being an Xbox authentication IP address one day.
>
> Josh Luthman
> 24/7 Help Desk: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
>
>
> On Tue, Nov 3, 2020 at 2:59 PM Mike Hammett  wrote:
>
>> Azure?
>>
>>
>>
>> -
>> Mike Hammett
>> Intelligent Computing Solutions 
>> 
>> 
>> 
>> 
>> Midwest Internet Exchange 
>> 
>> 
>> 
>> The Brothers WISP 
>> 
>> 
>> --
>> *From: *"Max Tulyev" 
>> *To: *nanog@nanog.org
>> *Sent: *Tuesday, November 3, 2020 1:55:45 PM
>> *Subject: *Microsoft is hacking my Asterisk??? O_o
>>
>> Hi All,
>>
>> I have just seen a number of IPs trying to brute-force my VoIP server
>> from Microsoft network. For example, 13.90.148.133, 20.55.203.249,
>> 40.76.244.210... Traceroute really goes to MSN. More than a half of all
>> usual attempts to hack my Asterisk I got today, came from MSN.
>>
>> What is happening? Am I missed something?
>>
>>
>

Re: Microsoft is hacking my Asterisk??? O_o

[Dovid Bender]

No it's not Microsoft. Welcome to the internet. It's probably someone on
Azure trying to find vulnerable systems. Have a look at some of the Videos
from Astricon explaining the pitfalls of voip fraud and security.

https://www.youtube.com/watch?v=9Wzzlo1kfTQ (disclaimer: that's my talk)
https://www.youtube.com/watch?v=CCDqpJc2aXQ
https://www.youtube.com/watch?v=h5Fw70KzAls
https://www.youtube.com/watch?v=hLFz8mlmKIY




On Tue, Nov 3, 2020 at 2:55 PM Max Tulyev  wrote:

> Hi All,
>
> I have just seen a number of IPs trying to brute-force my VoIP server
> from Microsoft network. For example, 13.90.148.133, 20.55.203.249,
> 40.76.244.210... Traceroute really goes to MSN. More than a half of all
> usual attempts to hack my Asterisk I got today, came from MSN.
>
> What is happening? Am I missed something?
>

Re: Cogent emails

[Dovid Bender]

The question is if they are back to contacting the names on whois or they
magically found our emails "another way" and they have plausible
deniability.


On Mon, Sep 14, 2020 at 1:07 PM David Guo  wrote:

> Yes, every week
>
>
>
> Proof
>
>
>
> https://vip1.loli.net/2020/09/15/bq3lHGuvNRkW9YS.jpg
>
>
>
> *From:* NANOG  * On Behalf Of *Dovid
> Bender
> *Sent:* Tuesday, September 15, 2020 12:46 AM
> *To:* NANOG 
> *Subject:* Cogent emails
>
>
>
> Is anyone starting to get the "cogent emails" again?
>
>
>
>
>

Cogent emails

[Dovid Bender]

Is anyone starting to get the "cogent emails" again?

Re: RPKI for dummies

[Dovid Bender]

To John and the others that have responded thanks for all the explanations.
It makes things a lot clearer now.

On Thu, Aug 20, 2020 at 10:15 AM John Kristoff  wrote:

> On Thu, 20 Aug 2020 13:20:53 +
> Dovid Bender  wrote:
>
> > How do ISP's that receive my advertisement (either directly from me,
> > meaning my upstreams or my upstreams upstream) verify against the
> > cert that the advertisement is coming from me?
>
> Nothing about your BGP announcements needs to change.  Through ARIN you
> create one or more route origin authorizations (ROAs) with your public
> key.  ARIN can even do all the work of creating the key pair for you if
> you like.  You might try creating test ROAs in their operational test
> and evaluation environment (OTE) environment to see how this process of
> creating a ROA works.
>
> ISPs obtain these ROAs apart and separately from the BGP  system.  ISPs
> that fetch your ROA(s) and other RPKI objects through the RPKI
> ecosystem, perform validation, and communicate AS origin and prefix
> information contained in these ROAs to BGP routers.  At that point
> this information is used to inform the route decision process,
> comparing received routes with processed ROAs as part of a route
> import policy.
>
> > If say we have Medium ISP (AS1000) -> Large ISP (AS200) in the above
> > case AS200 know it's peering with AS1000 so it will take all
> > advertisements. What's stopping AS1000 from adding a router to their
> > network to impersonate me,  make it look like I am peering with them
> > and then they re-advertise the path to Large ISP?
>
> In a nutshell, today, ISPs will only be able to validate the prefix and
> origin AS you publish in the ROA, this is known as route origin
> validation (ROV).  Today someone could advertise your prefix and
> post-pend your AS to appear as the origin.
>
> People are working madly on solutions to protecting other parts of the
> BGP route attributes the origin AS, but nothing is currently, widely
> deployed to provide that protection with the RPKI today.
>
> John
>

Re: RPKI for dummies

[Dovid Bender]

Ok. So here is another n00b question. Why don't we have something where
when we advertise IP space we also pass along a cert that can
independently be verified by going back to the RIR to see if that cert was
signed by them. This would also stop someone spoofing my ASN.


On Thu, Aug 20, 2020 at 10:53 AM Tom Beecher  wrote:

> ROA = Route Origin Authorization . Origin is the key word.
>
> When you create an signed ROA and do all the publishing bits, RPKI
> validator software will retrieve that , validate the signature, and pass
> that up to routers, saying "This prefix range that originates from this ASN
> is valid." Then, any BGP advertisement that contains a prefix in that
> range, with an origin ASN that matches, is treated as valid. The
> intermediary as-path isn't a factor.
>
> If another ASN ORIGINATES an announcement for your space, then RPKI
> routers will treat that announcement as INVALID, because that isn't
> authorized.
>
> If another ASN spoofs your ASN , pretending that they are your upstream,
> RPKI won't solve that. But that is a different problem set.
>
> On Thu, Aug 20, 2020 at 10:02 AM Dovid Bender  wrote:
>
>> Fabien,
>>
>> Thanks. So to sum it up there is nothing stopping a bad actor from
>> impersonating me as if I am BGP'ing with them. It's to stop any other AS
>> other then mine from advertising my IP space. Is that correct? How is
>> verification done? They connect to the RIR and verify that there is  a cert
>> signed by the RIR for my range?
>>
>>
>>
>> On Thu, Aug 20, 2020 at 9:51 AM Fabien VINCENT (NaNOG) via NANOG <
>> nanog@nanog.org> wrote:
>>
>>> Hi,
>>>
>>> In fact, RPKI does nothing about AS Path checks if it's your question.
>>> RPKI is based on ROA where signatures are published to guarantee you're the
>>> owner of a specific prefix with optionnal different maxLength from your
>>> ASN.
>>>
>>> So if the question is about if RPKI is sufficient to secure the whole
>>> BGP path, well, it's not. RPKI guarantee / permit only to verify the
>>> ressource announcements (IPvX block) is really owned by your ASN. But even
>>> if it's not sufficient, we need to deploy it to start securing resources',
>>> not the whole path.
>>>
>>> Don't know if it replies to your question, but you can read also the
>>> pretty good documentation on RPKI here :
>>> https://rpki.readthedocs.io/en/latest/rpki/introduction.html or the
>>> corresponding RFC ;)
>>>
>>> Le 20-08-2020 15:20, Dovid Bender a écrit :
>>>
>>> Hi,
>>>
>>> I am sorry for the n00b question. Can someone help point me in the right
>>> direction to understand how RPKI works? I understand that from my side that
>>> I create a key, submit the public portion to ARIN and then send a signed
>>> request to ARIN asking them to publish it. How do ISP's that receive my
>>> advertisement (either directly from me, meaning my upstreams or my
>>> upstreams upstream) verify against the cert that the advertisement is
>>> coming from me? If say we have
>>> Medium ISP (AS1000) -> Large ISP (AS200)
>>> in the above case AS200 know it's peering with AS1000 so it will take
>>> all advertisements. What's stopping AS1000 from adding a router to their
>>> network to impersonate me,  make it look like I am peering with them and
>>> then they re-advertise the path to Large ISP?
>>>
>>> Again sorry for the n00b question, I am trying to make sense of how it
>>> works.
>>>
>>> TIA.
>>>
>>> Dovid
>>>
>>>
>>> --
>>> *Fabien VINCENT*
>>> *@beufanet*
>>>
>>

Re: RPKI for dummies

[Dovid Bender]

Fabien,

Thanks. So to sum it up there is nothing stopping a bad actor from
impersonating me as if I am BGP'ing with them. It's to stop any other AS
other then mine from advertising my IP space. Is that correct? How is
verification done? They connect to the RIR and verify that there is  a cert
signed by the RIR for my range?



On Thu, Aug 20, 2020 at 9:51 AM Fabien VINCENT (NaNOG) via NANOG <
nanog@nanog.org> wrote:

> Hi,
>
> In fact, RPKI does nothing about AS Path checks if it's your question.
> RPKI is based on ROA where signatures are published to guarantee you're the
> owner of a specific prefix with optionnal different maxLength from your
> ASN.
>
> So if the question is about if RPKI is sufficient to secure the whole BGP
> path, well, it's not. RPKI guarantee / permit only to verify the ressource
> announcements (IPvX block) is really owned by your ASN. But even if it's
> not sufficient, we need to deploy it to start securing resources', not the
> whole path.
>
> Don't know if it replies to your question, but you can read also the
> pretty good documentation on RPKI here :
> https://rpki.readthedocs.io/en/latest/rpki/introduction.html or the
> corresponding RFC ;)
>
> Le 20-08-2020 15:20, Dovid Bender a écrit :
>
> Hi,
>
> I am sorry for the n00b question. Can someone help point me in the right
> direction to understand how RPKI works? I understand that from my side that
> I create a key, submit the public portion to ARIN and then send a signed
> request to ARIN asking them to publish it. How do ISP's that receive my
> advertisement (either directly from me, meaning my upstreams or my
> upstreams upstream) verify against the cert that the advertisement is
> coming from me? If say we have
> Medium ISP (AS1000) -> Large ISP (AS200)
> in the above case AS200 know it's peering with AS1000 so it will take all
> advertisements. What's stopping AS1000 from adding a router to their
> network to impersonate me,  make it look like I am peering with them and
> then they re-advertise the path to Large ISP?
>
> Again sorry for the n00b question, I am trying to make sense of how it
> works.
>
> TIA.
>
> Dovid
>
>
> --
> *Fabien VINCENT*
> *@beufanet*
>

RPKI for dummies

[Dovid Bender]

Hi,

I am sorry for the n00b question. Can someone help point me in the right
direction to understand how RPKI works? I understand that from my side that
I create a key, submit the public portion to ARIN and then send a signed
request to ARIN asking them to publish it. How do ISP's that receive my
advertisement (either directly from me, meaning my upstreams or my
upstreams upstream) verify against the cert that the advertisement is
coming from me? If say we have
Medium ISP (AS1000) -> Large ISP (AS200)
in the above case AS200 know it's peering with AS1000 so it will take all
advertisements. What's stopping AS1000 from adding a router to their
network to impersonate me,  make it look like I am peering with them and
then they re-advertise the path to Large ISP?

Again sorry for the n00b question, I am trying to make sense of how it
works.

TIA.

Dovid

Re: cloud backup

[Dovid Bender]

Questions are asked here because of the variety of expertise that there is
here. I personally have gained a lot from the side lines seeing questions
and responses to items not directly related to bytes traveling over a wire.



On Sun, Jul 26, 2020 at 4:50 PM Tony Wicks  wrote:

> Did I miss something? Is this list now the newbie product questions list?
>
> -Original Message-
> From: NANOG  On Behalf Of
> Sent: Monday, 27 July 2020 8:40 am
> To: nanog@nanog.org
> Subject: Re: cloud backup
>
>
>

Re: cloud backup

[Dovid Bender]

https://wasabi.com/cloud-storage-pricing/#three-info



On Sun, Jul 26, 2020 at 4:09 PM Randy Bush  wrote:

> i backup using arq on macos catalina.  on two macs, i need maybe 3-4tb
> max.  google seems to be $100/mo for 20tb (big jump from $100/yr for
> 2tb).  backblaze b2 looks more like $20/mo for 4tb ($0.005/gb/mo).
> anyone else done a similar analysis?
>
> randy
>

Issues with Verizon FiOS

[Dovid Bender]

Can someone from Verizon contact me off the list. Our customers as well as
many others are experiencing packet loss on our Voice products

https://puck.nether.net/pipermail/outages/2020-June/013133.html
https://puck.nether.net/pipermail/outages/2020-June/013136.html

TIA

Re: Network card with relay in case of power failure

[Dovid Bender]

Yes TY.


On Wed, Jun 17, 2020 at 5:15 PM Yang Yu  wrote:

> something like
> https://www.chelsio.com/wp-content/uploads/2012/02/B420-021412.pdf
> ?
>
> On Wed, Jun 17, 2020 at 1:16 PM Dovid Bender  wrote:
> >
> > Hi,
> >
> > I am sorry if this is off topic.I was once demoed a network device that
> had two interfaces. The traffic would go through the device. If there was a
> power cut or some other malfunction there would be a relay that would
> physically bridge the two network interfaces so the traffic would flow as
> if it was just a network cable. Is anyone aware of such a network card or
> device?
> >
> > TIA.
> >
> >
>

Re: Quality of the internet

[Dovid Bender]

Yes. We have gotten a lot fo complaints today. Can't seem to nail it down.
Random PL.


On Wed, Jun 17, 2020 at 4:52 PM Izzy Goldstein - TeleGo <
igoldst...@telego.net> wrote:

> now you mentioned it, verizon fios is having issues in NY ?
>
> On Wed, Jun 17, 2020 at 4:50 PM Dovid Bender  wrote:
>
>> Hi,
>>
>> My 9-5 is working for a VoIP provider. When we started in 2006 we had a
>> lot of issues with the quality of the internet in eastern europe and
>> central Asia. It was not rare for us to have to play around with routing to
>> get the quality that we needed. In a review of tickets for the last two
>> years it seems as if we barely do any of that these days. Rarely do we get
>> a quality complaint that comes back to an issue where a carrier or ISP
>> dropping or mangling packets. Has anyone else observed this as well?
>>
>>
>>
>
> --
>
> Izzy Goldstein
>
> Chief Technology Officer
>
> Main: (212) 477-1000 x 2085 <(212)%20477-1000>
>
> Direct: (929) 477-2085
>
> Website: www.telego.com <http://www.telego.net/>
>
>
> <http://www.telego.com/>
>
>
> Confidentiality Notice: This e-mail may contain confidential and/or
> privileged information. If you are not the intended recipient or have
> received this e-mail in error please notify us immediately by email reply
> and destroy this e-mail. Any unauthorized copying, disclosure or
> distribution of the material in this e-mail is strictly forbidden. Any
> views or opinions presented in this email are solely those of the author
> and do not necessarily represent those of TeleGo (T). Employees of TeleGo
> are expressly required not to make defamatory statements and not to
> infringe or authorize any infringement of copyright or any other legal
> right by email communications. Any such communication is contrary to TeleGo
> policy and outside the scope of the employment of the individual concerned.
> TeleGo will not accept any liability in respect of such communication, and
> the employee responsible will be personally liable for any damages or other
> liability arising.
>
>
> TeleGo Hosted PBX <https://youtu.be/DaT8YAZ4V0w>
>

Quality of the internet

[Dovid Bender]

Hi,

My 9-5 is working for a VoIP provider. When we started in 2006 we had a lot
of issues with the quality of the internet in eastern europe and central
Asia. It was not rare for us to have to play around with routing to get the
quality that we needed. In a review of tickets for the last two years it
seems as if we barely do any of that these days. Rarely do we get a quality
complaint that comes back to an issue where a carrier or ISP dropping or
mangling packets. Has anyone else observed this as well?

Network card with relay in case of power failure

[Dovid Bender]

Hi,

I am sorry if this is off topic.I was once demoed a network device that had
two interfaces. The traffic would go through the device. If there was a
power cut or some other malfunction there would be a relay that would
physically bridge the two network interfaces so the traffic would flow as
if it was just a network cable. Is anyone aware of such a network card or
device?

TIA.

Re: Network issues in Israel/Middle East

[Dovid Bender]

John,

As others have mentioned you should be going to Europe we have a POP in
Rosh Hayain, IL and in Nicosia, CY. Both POP's backup to AWS Ireland.
Almost all of your traffic in IL is going to go through Western Europe so
it makes no sense to send it to India. Israel does not have any peering
with its neighbors.

I just did some tests from Bezeq in Petah Tiqwa

AWS Ireland
[root@cust-219-83-123 ~]# ping 3.248.0.0
PING 3.248.0.0 (3.248.0.0) 56(84) bytes of data.
64 bytes from 3.248.0.0: icmp_seq=1 ttl=223 time=69.0 ms
64 bytes from 3.248.0.0: icmp_seq=2 ttl=223 time=69.1 ms
^C

AWS Virginia
[root@cust-219-83-123 ~]# ping 3.80.0.0
PING 3.80.0.0 (3.80.0.0) 56(84) bytes of data.
64 bytes from 3.80.0.0: icmp_seq=1 ttl=238 time=149 ms
64 bytes from 3.80.0.0: icmp_seq=2 ttl=238 time=149 ms
^C

AWS Mumbai
[root@cust-219-83-123 ~]# ping 3.6.0.0
PING 3.6.0.0 (3.6.0.0) 56(84) bytes of data.
64 bytes from 3.6.0.0: icmp_seq=1 ttl=233 time=168 ms
64 bytes from 3.6.0.0: icmp_seq=2 ttl=233 time=168 ms
^C

AWS Milan
[root@cust-219-83-123 ~]# ping 15.161.0.254
PING 15.161.0.254 (15.161.0.254) 56(84) bytes of data.
64 bytes from 15.161.0.254: icmp_seq=1 ttl=239 time=58.5 ms
64 bytes from 15.161.0.254: icmp_seq=2 ttl=239 time=58.4 ms
^C

AWS London
[root@cust-219-83-123 ~]# ping 3.8.0.0
PING 3.8.0.0 (3.8.0.0) 56(84) bytes of data.
64 bytes from 3.8.0.0: icmp_seq=1 ttl=229 time=57.2 ms
64 bytes from 3.8.0.0: icmp_seq=2 ttl=229 time=57.2 ms
^C

AWS Frankfurt
[root@cust-219-83-123 ~]# ping 3.120.0.0
PING 3.120.0.0 (3.120.0.0) 56(84) bytes of data.
64 bytes from 3.120.0.0: icmp_seq=1 ttl=235 time=50.7 ms
64 bytes from 3.120.0.0: icmp_seq=2 ttl=235 time=50.7 ms
^C


It seems like you're better off going to the US over going to Mumbai!



On Mon, May 25, 2020 at 3:00 PM John Von Essen  wrote:

> I know this is outside the scope of “North America”, but has anyone else
> been fielding more issues related to network health/congestion in the
> middle east, specifically Israel?
>
> Our users in Israel are primarily served from India-based resources
> (AWS/Azure), both of which have cloud capacity issues in India that I’m
> aware of.
>
> Also, the majority of our users in Israel that have been reporting
> slowness seem to be mostly behind the ISP Bezeq. If we force them to route
> to Ireland (which is technically farther away form a latency standpoint)
> things are much better, so I’m wondering if just Bezeq (or everyone in
> Israel) is just experiencing 3rd party-related network congestion to Mumbai.
>
> Thanks
> John
>
>
>

Re: LTE modem where I can control the MTU

[Dovid Bender]

I currently have an airlink that is connected directly to a raritan console
server. The public IP sits on the raritan. The airlink does not seem to
have any MTU options. Ideally I would change the MTU on the interface of
the LTE modem wich would force the raritan to send all data < 1400 bytes
per packet. I never thought about the reverse so we may need something that
would tinker with the MSS as well.


On Fri, May 1, 2020 at 11:01 AM Phil Lavin  wrote:

> > We have VZ wireless in the data center as a backup to our core
> infrastructure. We have an issue where if packets have a large MTU they
> seem to die. Does anyone know of a good 4G modem where I can set the MTU on
> the cellular connection?
>
> I suspect it's a bit more complex than just changing LTE MTU. The time
> when MTU matters in this situation (larger packets getting lost) is when DF
> bit is set on the packet - that's the case for all TCP data packets and it
> often crops up during TLS negotiations. Is that what you're seeing?
>
> Consider the following scenario:
>
> Your Server---Switch---LTE Router---T'Internet---Another
> Network---Other Server
>
> If both "Your Server" and "Other Server" are connected to their relevant
> local networks at 1500 MTU then they will negotiate a TCP MSS slightly
> below 1500 bytes (probably 1460 bytes???) because they have no concept of
> the path MTU. If the MTU between LTE Router and the Internet is below 1500
> then the LTE Router will drop larger packets because it's not allowed to
> fragment them.
>
> The solutions are:
>
> :: Have the LTE Router reduce the MSS of TCP negotiation packets as they
> flow through it. This is the approach normally taken by any cheap DSL
> router so I'd think your current LTE router should be able to do this also
> :: Have the LTE Router strip the DF bit from packets and fragment them
> anyway. I don't have any particular experience/opinions either way on this
> one so I'll leave it to others to comment/berate
> :: Implement path MTU discovery so your devices are aware of the path MTU
> and so set their MSS accordingly
>
>
>

LTE modem where I can control the MTU

[Dovid Bender]

Hi,

We have VZ wireless in the data center as a backup to our core
infrastructure. We have an issue where if packets have a large MTU they
seem to die. Does anyone know of a good 4G modem where I can set the MTU on
the cellular connection?

TIA.

Dovid

Re: Phishing and telemarketing telephone calls

[Dovid Bender]

STIR/SHAKEN?

On Mon, Apr 27, 2020, 14:34 Michael Thomas  wrote:

>
> On 4/27/20 11:12 AM, Jon Lewis wrote:
> > On Mon, 27 Apr 2020, William Herrin wrote:
> >
> >> On Sat, Apr 25, 2020 at 7:32 PM Matthew Black
> >>  wrote:
> >>> Good grief, selling a kit for $47. Since all robocalls employ Caller
> >>> ID spoofing, just how does one prove who called?
> >>
> >> You don't. AFAICT, that's the point of Anne's comments. Finding them
> >> is good enough. Paying off anyone who both finds them and appears well
> >> connected with the law is cheaper than allowing the legal system to
> >> become aware of their identities and activity.
> >>
> >> Blackmail 101 dude. Find someone with a secret and demand payment for
> >> your silence. The best part is that if you're legitimately entitled to
> >> the money because of the secret then it's not technically blackmail.
> >>
> >> Presumably the meat of the $47 kit is about how to tease out enough
> >> clues to search public records and identify them.
> >
> > In my experience, the caller-id is always forged, and the call center
> > reps hang up or give uselessly vague answers if I ask what company
> > they're calling from.  I suspect the only sure way to identify them is
> > to do business with them, i.e. buy that extended warranty on your car,
> > or at least start walking through the process until either payment is
> > made or they tell you who you'll have to pay.  I wonder, if you agree
> > to buy the extended warranty, solely for the purpose of identifying
> > them, can you immediately cancel it / dispute the charge?
> >
> > Then there are the 100% criminal ones calling from "Windows Technical
> > Support" who want to trick you into giving them remote admin access to
> > your PC.  I assume that's a dry well and the best you can hope to do
> > is waste as much of their time as yours and see how foul a mouth they
> > have.
> >
> On the IETF list, I've been making the case that a DKIM-like solution
> for SIP signalling would in fact give you the way to blame somebody,
> which was DKIM's entire raison d'etre. Who cares what the actual fake
> e.164 address is and whether the sending domain is allowed to assert it
> or not? That is rather beside the point. All I care is that the
> originating domain is supporting abuse, and I know what the domain is to
> complain to, ignore, etc.
>
> Mike
>
>
>

Re: Comcast - Significant v4 vs v6 throughput differences, almost stateful.

[Dovid Bender]

We have customers in CT with the same issues. When did this start?


On Thu, Apr 23, 2020 at 11:07 AM Nick Zurku  wrote:

> Hello all,
>
> I would appreciate if someone from Comcast could contact me about this.
>
> We’re having serious throughput issues with our AS20326 pushing packets to
> Comcast over v4. Our transfers are either the full line-speed of the
> Comcast customer modem, or they’re seemingly capped at 200-300KB/s. This
> behavior appears to be almost stateful, as if the speed is decided when the
> connection starts. As long as it starts fast it will remain fast for the
> length of the transfer and slow if it starts slow. Traces seem reasonable
> and currently we’ve influenced the path onto GTT both ways. If we prepend
> and reroute on our side, the same exact issue with happen on another
> transit provider.
>
> This issue does not affect v6 and that is full speed on every attempt.
> This may be regionalized to the Comcast Pittsburgh market.
>
> This is most widely affecting our linux mirror repository server:
> http://mirror.pit.teraswitch.com/
> Our colocation customers who are hosting VPN systems are also noticing
> bottlenecks have started recently for their Comcast employees.
>
> --
> Nick Zurku
> Systems Engineer
> TeraSwitch, Inc.
> nzu...@teraswitch.com
>

Re: he.net certificate expiriation

[Dovid Bender]

They know about it and when their system admins get in it will be
corrected. It's interesting because all of their other sites (e.g.
https://he.net) has a wild card that is valid till 2021.


On Wed, Feb 26, 2020 at 10:44 AM Steve Jones 
wrote:

> The *.he.net cert expired today so the looking glass is inaccessible from
> chrome if anyone here has a contact to rectify
>

Re: FYI - Suspension of Cogent access to ARIN Whois

[Dovid Bender]

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.


On Mon, Jan 27, 2020 at 12:56 PM Owen DeLong  wrote:

> I now longer have a dog in this fight, but “The” peering cake was my
> project (such as it was)...
>
> Cogent has, to the best of my knowledge, always had rather large voids in
> their IPv6 connectivity. To the best of my knowledge, HE and Google are the
> most significant of these voids, but I believe there are others as well.
>
> Some quotes I received from Cogent representatives over the years (some
> may be slightly paraphrased):
>
> “Hurricane is too small to peer IPv6 with us… They should just buy
> transit from us.”
> “Why should we peer with HE? Our customers aren’t reporting it as
> a problem.”
> “Congested links allow us to pass the savings on to our customers.”
> “We see from ARIN whois that you recently registered an ASN. Want
> to buy transit from us?” (many times over several years)
> (This particular violation of the ARIN Whois AUP/TOS
> eventually resulted in Cogent being suspended from using the service)
>
> Owen
>
>
> > On Jan 26, 2020, at 22:41 , Large Hadron Collider <
> large.hadron.colli...@gmx.com> wrote:
> >
> > Peering cake? Carbohydrates always entice me to peer... :-)
> >
> > On Wed, 8 Jan 2020 10:16:12 -0600
> > "Aaron Gould"  wrote:
> >
> >> I’m pretty sure cogent has had issues providing full internet
> connectivity via ipv6 to google and perhaps he (hurricane electric),
> perhaps others as well, for quite some time now.
> >>
> >>
> >>
> >> -Aaron
> >>
> >>
> >>
> >> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of James Breeden
> >> Sent: Tuesday, January 7, 2020 7:04 PM
> >> To: Rich Kulawiec; North American Network Operators' Group
> >> Subject: RE: FYI - Suspension of Cogent access to ARIN Whois
> >>
> >>
> >>
> >> Hmm. Wonder if this can be used to cancel some cogent services... I
> mean, they technically aren't providing access to the full internet now.
> 路‍♂️樂
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> Sent via the Samsung Galaxy Note9, an AT 5G Evolution capable
> smartphone
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>  Original message 
> >>
> >> From: Rich Kulawiec 
> >>
> >> Date: 1/7/20 7:02 PM (GMT-06:00)
> >>
> >> To: North American Network Operators' Group 
> >>
> >> Subject: Re: FYI - Suspension of Cogent access to ARIN Whois
> >>
> >>
> >>
> >> On Tue, Jan 07, 2020 at 04:54:22PM -0600, Mike Hammett wrote:
> >>> That said, if there's a stern warning about Cogent abusing the system,
> >>> maybe their customers finding out is a good thing for the overall
> >>> community. ;-)
> >>
> >> And that is what I would suggest: reply to all queries with a notice
> >> that explains what is happening, why it's happening, and provides
> >> contact information for Cogent executives: preferably their *personal*
> >> email addresses and phone numbers.
> >>
> >> ---rsk
> >>
> >
> >
> > --
> > Large Hadron Collider 
>
>

Re: End to End testing

[Dovid Bender]

Are you looking to see what happens if latency is added? Have a look at
https://iwl.com/products-solutions/products/maxwell-pro



On Thu, Dec 12, 2019 at 9:54 AM Fawcett, Nick via NANOG 
wrote:

> Anyone have any suggestions on devices that I can put at two points in the
> network to test packet loss, latency, jitter etc.  I was thinking of maybe
> engineering my own using a couple of pi’s,  but the downfall is they don’t
> have SFP ports.  I’m looking for something that’s portable and easy to
> configure and drop in.  Thanks.
>
>
>
> ~Nick
>
>
>
> --
> Checked by SOPHOS http://www.sophos.com
>
>

Re: Best components for a full mvno core network?

[Dovid Bender]

Dario,

They were very helpful when I went over to them afterwards and asked
questions. If you are interested in an intro let me know.

On a side note Commcon took a lot of effort and there wasn't enough
sponsorship so it may not happen in 2020. If anyone else glances over
videos, finds them useful and would want to sponsor I can put them in touch
with the shows host.



On Thu, Oct 31, 2019 at 11:54 AM Dario Renaud 
wrote:

> Thanks Dovid.
>
> Sipgate needs seems very similar to our own and I’ve got quite a few good
> pointers from that talk.
>
> By the way, a lot of these comcon sessions looks quite interesting, I
> think I will play a few others.
>
> Le mer. 30 oct. 2019 à 23:49, Dovid Bender  a écrit :
>
>> This was discussed in detail at commcon. Have a look at
>> https://www.youtube.com/watch?v=4HdGuCFQYMs=PLvNS4EBAxmJKz6E6PLCqBq0eB-KKB6HR0=21=0s
>>
>>
>>
>> On Mon, Oct 21, 2019 at 12:51 PM Dario Renaud 
>> wrote:
>>
>>> Hello Javier,
>>>
>>> Well, if we take a step back to goals, I would like first to point that
>>> going Full MVNO might not be the best solution for us (roaming alone seems
>>> like quite a hassle, not to mention handsets management).
>>>
>>> My focus here is narrower, as I am mostly trying here to assert what the
>>> possibilities for the core are, and if there are reasonable alternatives to
>>> the fully integrated solutions of the big providers.
>>>
>>> That being said, I am not sure how our specific goals here would impact
>>> much the architecture: aren’t there a lot of constraints due to the 3GPP
>>> requirements?  It seems to leave little room for creativity.
>>>
>>> To provide a bit of context and answer you:
>>>
>>> We are historically providing solutions on fixed networks, with a strong
>>> bend toward business end-users. We are also used to have a lot of control
>>> over our architecture, most of our services running over open-source and/or
>>> in-house solutions.
>>>
>>> Being able to provide our services on mobile accesses is now a
>>> necessity. For this we already are light MVNO, using two different MNOs.
>>> Thanks to forced routing, it mostly does the job regarding voice. Data
>>> could be managed also. SMS is proving trickier.
>>>
>>> But each MNO have their own products set: building offers that would
>>> work on both is tedious and necessitate compromises that tend to make our
>>> marketing people unhappy. Not to talk about supporting two provisioning
>>> chains, two SIMs supply chains, etc… These problems would only get worse if
>>> we add other MNOs to the mix.
>>>
>>> We are also stuck with the roadmap of the MNOs (VoLTE and VoWifi are but
>>> distant “maybe later” possibilities).
>>>
>>> So, in one word, this is about autonomy. And its cost.
>>>
>>> Regards,
>>>
>>> Dario Renaud
>>>
>>> Le ven. 18 oct. 2019 à 17:44, Javier J  a
>>> écrit :
>>>
>>>> This is interesting but so many variables to unpack to determin what
>>>> the right solution is. What are the main goals of your org? What exact pain
>>>> points are you trying to fix?
>>>>
>>>>
>>>>
>>>> On Wed, Oct 16, 2019, 8:28 AM Dario Renaud 
>>>> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> At my day job, we are considering going Full MVNO. Which means
>>>>> building a mobile core network.
>>>>>
>>>>> I was wondering if some of you would have feedback or advices on the
>>>>> solutions currently available?
>>>>>
>>>>> We would like to avoid the big providers (Ericsson & such).
>>>>> Ideally, something opensource, or, if proprietary, a company maybe
>>>>> willing to license access to the code (one can dream).
>>>>>
>>>>> There seems to be a lot of bits and pieces available out there, with a
>>>>> mix of full, fullish or partial solutions. This makes for quite the 
>>>>> puzzle.
>>>>>
>>>>> Among the ones I found most interesting:
>>>>>
>>>>> nextEPC, covering, well, the EPC… (https://github.com/nextepc/nextepc).
>>>>> It looks like the more active open EPC implementation out there.
>>>>>
>>>>> And it seems that Yate people have a commercial product covering
>>>>> basically everything needed (
>>>>> https://yatebts.com/solutions_and_technology/mobile_virtual_network_operator/).
>>>>>
>>>>>
>>>>> What do you think?
>>>>>
>>>>> Regards
>>>>>
>>>>> Dario Renaud
>>>>>
>>>>

Re: Best components for a full mvno core network?

[Dovid Bender]

This was discussed in detail at commcon. Have a look at
https://www.youtube.com/watch?v=4HdGuCFQYMs=PLvNS4EBAxmJKz6E6PLCqBq0eB-KKB6HR0=21=0s



On Mon, Oct 21, 2019 at 12:51 PM Dario Renaud 
wrote:

> Hello Javier,
>
> Well, if we take a step back to goals, I would like first to point that
> going Full MVNO might not be the best solution for us (roaming alone seems
> like quite a hassle, not to mention handsets management).
>
> My focus here is narrower, as I am mostly trying here to assert what the
> possibilities for the core are, and if there are reasonable alternatives to
> the fully integrated solutions of the big providers.
>
> That being said, I am not sure how our specific goals here would impact
> much the architecture: aren’t there a lot of constraints due to the 3GPP
> requirements?  It seems to leave little room for creativity.
>
> To provide a bit of context and answer you:
>
> We are historically providing solutions on fixed networks, with a strong
> bend toward business end-users. We are also used to have a lot of control
> over our architecture, most of our services running over open-source and/or
> in-house solutions.
>
> Being able to provide our services on mobile accesses is now a necessity.
> For this we already are light MVNO, using two different MNOs. Thanks to
> forced routing, it mostly does the job regarding voice. Data could be
> managed also. SMS is proving trickier.
>
> But each MNO have their own products set: building offers that would work
> on both is tedious and necessitate compromises that tend to make our
> marketing people unhappy. Not to talk about supporting two provisioning
> chains, two SIMs supply chains, etc… These problems would only get worse if
> we add other MNOs to the mix.
>
> We are also stuck with the roadmap of the MNOs (VoLTE and VoWifi are but
> distant “maybe later” possibilities).
>
> So, in one word, this is about autonomy. And its cost.
>
> Regards,
>
> Dario Renaud
>
> Le ven. 18 oct. 2019 à 17:44, Javier J  a
> écrit :
>
>> This is interesting but so many variables to unpack to determin what the
>> right solution is. What are the main goals of your org? What exact pain
>> points are you trying to fix?
>>
>>
>>
>> On Wed, Oct 16, 2019, 8:28 AM Dario Renaud 
>> wrote:
>>
>>> Hello,
>>>
>>> At my day job, we are considering going Full MVNO. Which means building
>>> a mobile core network.
>>>
>>> I was wondering if some of you would have feedback or advices on the
>>> solutions currently available?
>>>
>>> We would like to avoid the big providers (Ericsson & such).
>>> Ideally, something opensource, or, if proprietary, a company maybe
>>> willing to license access to the code (one can dream).
>>>
>>> There seems to be a lot of bits and pieces available out there, with a
>>> mix of full, fullish or partial solutions. This makes for quite the puzzle.
>>>
>>> Among the ones I found most interesting:
>>>
>>> nextEPC, covering, well, the EPC… (https://github.com/nextepc/nextepc).
>>> It looks like the more active open EPC implementation out there.
>>>
>>> And it seems that Yate people have a commercial product covering
>>> basically everything needed (
>>> https://yatebts.com/solutions_and_technology/mobile_virtual_network_operator/).
>>>
>>>
>>> What do you think?
>>>
>>> Regards
>>>
>>> Dario Renaud
>>>
>>

Re: Poor mans TAP

[Dovid Bender]

Yup, Tried that. Incoming interface is set as:
interface Ethernet1/37
  switchport mac-learn disable
  description tor-31-1 ge-0/0/44 SPAN
  switchport mode trunk
  switchport trunk allowed vlan 2,999
  ip access-group DROP out

Outbound interfaces are set to:

interface Ethernet1/46
  description MON1
  switchport access vlan 999

The issue is that the traffic coming in, is coming from a Juniper switch
where the traffic has vlan tags on the packets.


On Mon, Oct 7, 2019 at 1:07 PM Nick Hilliard  wrote:

> Dovid Bender wrote on 07/10/2019 17:56:
> > We used cisco in the past. The issue we have is the switches that will
> > mirror to more than one port  have fans pushing the heat into the cold
> > isle. From what I was able to see Cisco does not have any AFO switches
> > that will mirror to more than one port.
>
> um, really?  Have you tried disabling mac learning?  This will cause all
> traffic to be unicast flooded to multiple ports.
>
> Nick
>

Re: Poor mans TAP

[Dovid Bender]

John,

We used cisco in the past. The issue we have is the switches that will
mirror to more than one port  have fans pushing the heat into the cold
isle. From what I was able to see Cisco does not have any AFO switches that
will mirror to more than one port.



On Mon, Oct 7, 2019 at 10:29 AM John Kristoff  wrote:

> On Mon, 7 Oct 2019 14:16:31 +
> Dovid Bender  wrote:
>
> > Funds at my 9-5 are limited. Has anyone tried this and how well does
> > it work? We plan on mirroring about 800 megs of traffic at peak.
> >
> https://www.amazon.com/Dualcomm-1000Base-T-Ethernet-Regeneration-Network/dp/B0055M5JL8?ref_=ast_bbp_dp
>
> I don't know if it still works on modern switches, but many years ago I
> was able to have Cisco LAN switches configured such that a single L2
> MAC address could be statically associated with multiple interfaces
> (i.e. router interface).  This made it possible to duplicate all
> traffic to destined to one station to appear on two (maybe more?) ports.
> You might try this also if you have an unused and available switch.
>
> John
>

Poor mans TAP

[Dovid Bender]

Hi,

Funds at my 9-5 are limited. Has anyone tried this and how well does it
work? We plan on mirroring about 800 megs of traffic at peak.
https://www.amazon.com/Dualcomm-1000Base-T-Ethernet-Regeneration-Network/dp/B0055M5JL8?ref_=ast_bbp_dp

TIA.

Dovid

Re: IPv6 Thought Experiment

[Dovid Bender]

Antonios,

It's certainly financial but it's not just companies being cheap. For
example for smaller companies with a limited staff and small margins. They
may want to have v6 everywhere but lack the resources to do it. It would
for certain speed up the process but there would be collateral damage in
the process.



On Wed, Oct 2, 2019 at 12:34 PM Antonios Chariton 
wrote:

> Dear list,
> First of all, let me apologize if this post is not allowed by the list. To
> my best interpretation of the guidelines [1] it is allowed, but may be in a
> gray area due to rule #7.
>
> I would like to propose the following thought experiment about IPv6, and I
> would like your opinion on what you believe would happen in such a case.
> Feel free to reply on or off list.
>
> What if, globally, and starting at January 1st, 2020, someone (imagine a
> government or similar, but with global reach) imposed an IPv4 tax. For
> every IPv4 address on the Global Internet Routing Table, you had to pay a
> tax. Let’s assume that this can be imposed, must be paid, and cannot be
> avoided using some loophole. Let’s say that this tax would be $2, and it
> would double, every 3 or 6 months.
>
> What do you think would happen? Would it be the only way to reach 100%
> IPv6 deployment, or even that wouldn’t be sufficient?
>
> And for bonus points, consider the following: what if all certification
> bodies of equipment, for certifications like FCC’s or CE in Europe, for
> applications after Jan 1st 2023 would include a “MUST NOT support IPv4”..
>
> What I am trying to understand is whether deploying IPv6 is a pure
> financial problem. If it is, in this scenario, it would very very soon
> become much more pricey to not deploy it.
>
> I know there are a lot of gaps in this, for example who imposes this, what
> is the "Global Internet Routing Table", etc. but let’s try to see around
> them, to the core idea behind them.
>
> Thanks,
> Antonis
>
> ---
> Links
> ---
> 1: https://nanog.org/resources/usage-guidelines/
>

Re: Spectrum (Charter) Fragmented UDP

[Dovid Bender]

Wait till STIR/SHAKEN is enabled. Were going to see real quickly who isn't
handling fragmentation correctly...


On Wed, Oct 2, 2019 at 8:34 AM Saku Ytti  wrote:

> Hey Phil,
>
> > At some point over night on 30th September (i.e. the night going into
> 1st October), we saw a number of Spectrum (Charter) customers stop handling
> fragmented UDP packets. This has manifested itself in such that the phones
> of affected customers are no longer receiving UDP SIP INVITE packets which
> exceed whatever their WAN side MTU is. We've so far had 6 customers report
> the issue - we can see that the last call on 30th September worked and the
> first and subsequent calls on 1st October failed.
> >
> > Is anyone aware of an update to CPE devices pushed out that night which
> may have broken their ability to handle IP fragmentation?
>
> I don't know anything specific to this case, but you'd serve your best
> interest to send small enough packets that do not need fragmentation,
> particularly in the backbone. Even devices often considered SP
> quality, such as ASR9k, fragment in the linecard CPU, giving very poor
> service quality compared to sending two packets not fragmented.
>
> While we can say this should just work, the reality is, it's not very
> reliably true and I would not build product or business on the
> assumption that it works well.
> --
>   ++ytti
>

OT: Tech bag

[Dovid Bender]

Hi,

Sorry for the OT email. I travel extensively to DC's and my computer bag
seems to keep collecting more tools which includes your usual console
cables, spare everything, two laptops etc. My Swissgear has been taking a
beating and I was wondering what others who have to lug around 30-35 pounds
use.

TIA.

Re: CloudFlare issues?

[Dovid Bender]

We are seeing issues as well getting to HE. The traffic is going via Alter.



On Mon, Jun 24, 2019 at 7:48 AM Robbie Trencheny  wrote:

> From John Graham-Cumming, CTO of Cloudflare, on Hacker News right now:
>
> This appears to be a routing problem with Level3. All our systems are
> running normally but traffic isn't getting to us for a portion of our
> domains.
>
> 1128 UTC update Looks like we're dealing with a route leak and we're
> talking directly with the leaker and Level3 at the moment.
>
> 1131 UTC update Just to be clear this isn't affecting all our traffic or
> all our domains or all countries. A portion of traffic isn't hitting
> Cloudflare. Looks to be about an aggregate 10% drop in traffic to us.
>
> 1134 UTC update We are now certain we are dealing with a route leak.
>
> On Mon, Jun 24, 2019 at 04:04 Antonios Chariton 
> wrote:
>
>> Yes, traffic from Greek networks is routed through NYC (alter.net), and
>> previously it had a 60% packet loss. Now it’s still via NYC, but no packet
>> loss. This happens in GR-IX Athens, not GR-IX Thessaloniki, but the problem
>> definitely exists.
>>
>> Antonis
>>
>>
>> On 24 Jun 2019, at 13:55, Dmitry Sherman  wrote:
>>
>> Hello are there any issues with CloudFlare services now?
>>
>> Dmitry Sherman
>> dmi...@interhost.net
>> Interhost Networks Ltd
>> Web: http://www.interhost.co.il
>> fb: https://www.facebook.com/InterhostIL
>> Office: (+972)-(0)74-7029881 Fax: (+972)-(0)53-7976157
>>
>>
>> --
> --
> Robbie Trencheny (@robbie )
> 925-884-3728
> robbie.io
>

Re: Cellular backup connections

[Dovid Bender]

I am getting the same for SSH and https traffic. It's strange. Where the
response is something small like:

Moved to this https://63.XX.XX.XX:443/auth.asp;>location.

It works But when I try to load pages that are any bigger it fails. Like I
said before I assume it's either an issue with the MTU or window szie. I
was just wondering if anyone encountered such an issue before. It's not
easy getting to someone that knows something. When you have some sort of
concrete info the level1 techs tend to pass you along faster.





On Mon, Jun 24, 2019 at 7:41 AM J. Hellenthal 
wrote:

> Could be wrong on this but direct SSH on the LTE side may possibly be not
> allowed(filtered) and might just be something you could discuss in a ticket
> with Verizon.
>
> --
>  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 Jun 24, 2019, at 04:50, Dovid Bender  wrote:
>
> All,
>
> I finally got around to putting in a Verizon LTE connection and the ping
> times are pretty good. There is the occasional issue however for the most
> part ping times are < 50 ms. I have another strange issue though. When I
> try to ssh or connect via the endpoints web interface it fails. If I first
> connect via PPTP or SSL VPN then it works. I ruled out it being my IP since
> if I connect direct from the PPTP or SSL VPN box then it fails as well. It
> seems the tunnel does something (perhaps lowering the MTU or fragmenting
> packets) that allows it to work. Any thoughts?
>
> TIA.
>
>
>
>
> On Mon, Feb 4, 2019 at 8:18 AM Dovid Bender  wrote:
>
>> Anyone know if Verizon static IP's over LTE have same issue where they
>> bounce the traffic around before it gets back to the NY metro area?
>>
>>
>>
>> On Thu, Jan 3, 2019 at 6:46 PM Dovid Bender  wrote:
>>
>>> All,
>>>
>>> Thanks for all of the feedback. I was on site today and noticed two
>>> things.
>>> 1) As someone mentioned it could be for static IP's they have the
>>> traffic going to a specific location. The POP is in NJ there was a min.
>>> latency of 120ms which prob had to do with this.
>>> 2) I was watching the ping times and it looked something like this:
>>> 400ms
>>> 360ms
>>> 330ms
>>> 300ms
>>> 260ms
>>> 210ms
>>> 170ms
>>> 140ms
>>> 120ms
>>> 400ms
>>> 375ms
>>>
>>> It seems to have been coming in "waves". I assume this has to do with
>>> "how cellular work" and the signal. I tried moving it around by putting it
>>> down low on the floor, moving it locations etc. and saw the same thing
>>> every time. I am going to try Verizon next and see how it goes.
>>>
>>>
>>>
>>> On Sat, Dec 29, 2018 at 12:13 PM Mark Milhollan 
>>> wrote:
>>>
>>>> On Fri, 28 Dec 2018, Dovid Bender wrote:
>>>>
>>>> >I finally got around to setting up a cellular backup device in our new
>>>> POP.
>>>>
>>>> >When SSH'ing in remotely the connection seems rather slow.
>>>>
>>>> Perhaps using MOSH can help make the interactive CLI session less
>>>> annoying.
>>>>
>>>> >Verizon they charge $500.00 just to get a public IP and I want to
>>>> avoid
>>>> >that if possible.
>>>>
>>>> You might look into have it call out / maintain a connection back to
>>>> your infrastructure.
>>>>
>>>>
>>>> /mark
>>>>
>>>

Re: Cellular backup connections

[Dovid Bender]

All,

I finally got around to putting in a Verizon LTE connection and the ping
times are pretty good. There is the occasional issue however for the most
part ping times are < 50 ms. I have another strange issue though. When I
try to ssh or connect via the endpoints web interface it fails. If I first
connect via PPTP or SSL VPN then it works. I ruled out it being my IP since
if I connect direct from the PPTP or SSL VPN box then it fails as well. It
seems the tunnel does something (perhaps lowering the MTU or fragmenting
packets) that allows it to work. Any thoughts?

TIA.




On Mon, Feb 4, 2019 at 8:18 AM Dovid Bender  wrote:

> Anyone know if Verizon static IP's over LTE have same issue where they
> bounce the traffic around before it gets back to the NY metro area?
>
>
>
> On Thu, Jan 3, 2019 at 6:46 PM Dovid Bender  wrote:
>
>> All,
>>
>> Thanks for all of the feedback. I was on site today and noticed two
>> things.
>> 1) As someone mentioned it could be for static IP's they have the traffic
>> going to a specific location. The POP is in NJ there was a min. latency of
>> 120ms which prob had to do with this.
>> 2) I was watching the ping times and it looked something like this:
>> 400ms
>> 360ms
>> 330ms
>> 300ms
>> 260ms
>> 210ms
>> 170ms
>> 140ms
>> 120ms
>> 400ms
>> 375ms
>>
>> It seems to have been coming in "waves". I assume this has to do with
>> "how cellular work" and the signal. I tried moving it around by putting it
>> down low on the floor, moving it locations etc. and saw the same thing
>> every time. I am going to try Verizon next and see how it goes.
>>
>>
>>
>> On Sat, Dec 29, 2018 at 12:13 PM Mark Milhollan 
>> wrote:
>>
>>> On Fri, 28 Dec 2018, Dovid Bender wrote:
>>>
>>> >I finally got around to setting up a cellular backup device in our new
>>> POP.
>>>
>>> >When SSH'ing in remotely the connection seems rather slow.
>>>
>>> Perhaps using MOSH can help make the interactive CLI session less
>>> annoying.
>>>
>>> >Verizon they charge $500.00 just to get a public IP and I want to avoid
>>> >that if possible.
>>>
>>> You might look into have it call out / maintain a connection back to
>>> your infrastructure.
>>>
>>>
>>> /mark
>>>
>>

Re: CenturyLink/Level3 feedback

[Dovid Bender]

If the FCC has their way the only place you will see the PSTN in history
books. I can only hope that the same happens to faxing.


On Wed, Jun 5, 2019 at 4:37 PM Mike Hammett  wrote:

> It's amazing how inconsistent the PSTN is.
>
>
>
> -
> 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: *"Dovid Bender" 
> *To: *"Larry Brower" 
> *Cc: *"nanog" 
> *Sent: *Wednesday, June 5, 2019 3:31:36 PM
> *Subject: *Re: CenturyLink/Level3 feedback
>
> For voice there are so many IP options I don't know why anyone even messes
> with the old school carriers. About 4 years ago we signed up for L3 VoIP.
> We sent calls to France and the callerID didn't make it. We opened a ticket
> we were told callerID wasn't guaranteed on international calls. That was
> the day we canceled our service and asked for a refund. I am sometimes
> amazed how some of these carriers still have customers signing up.
>
>
>
> On Wed, Jun 5, 2019 at 8:50 AM Brower, Larry <
> larry.bro...@aramcoservices.com> wrote:
>
>> Mehmet,
>>
>>
>>
>> Speaking strictly on their voice product, service has gone a bit downhill
>> since the merger.
>>
>>
>>
>> We never had problems with Level3 before the merger.
>>
>>
>>
>> After Centurylink took over we started experiencing problems.
>>
>>
>>
>> Just a couple of examples:
>>
>>
>>
>> We waited months just to turn up a simple PRI. The PRI was sent back to
>> design several times and then when it finally was turned up it isn’t
>> working properly. The CL techs who were formally L3 express nothing but
>> frustration with dealing with CL following the merger. Complaints to the
>> account manager are met with just apologies and delays.
>>
>>
>>
>> International call routing has become unreliable. In the last month alone
>> we have had to create several service requests related to call failures.
>> The result after anywhere from a couple hours to a day is just hey we
>> rerouted try again. Then it works for a couple days and back to call
>> failures and intercept messages.
>>
>>
>>
>> I’ve already been asked if we should drop CenturyLink as the carrier and
>> go back to using someone like AT
>>
>>
>>
>> Never had any of these issue when it was Level3.
>>
>>
>>
>> Regards,
>>
>>
>>
>> Larry Brower, CCNP Collaboration, SSCA, RHCSA, CCDA, CCNA
>>
>> Communications Technician | Unified Communications Group
>>
>>
>>
>> Aramco Services Company
>>
>> *Office:  713.432.4516 | Mobile:  832.570.5416 *
>>
>> *larry.bro...@aramcoservices.com* 
>>
>>
>> This email has been classified as: *General Use* by *Brower, Larry *on 
>> *Wednesday,
>> June 5, 2019*
>>
>>
>>
>> *From:* NANOG  *On Behalf Of *Mehmet Akcin
>> *Sent:* Tuesday, June 4, 2019 9:31 AM
>> *To:* nanog 
>> *Subject:* CenturyLink/Level3 feedback
>>
>>
>>
>> *EXTERNAL: This email came from the Internet. Report this message to
>> ascsuspiciousem...@aramcoservices.com
>>  as suspicious if it contains any
>> suspicious content.*
>>
>> hi there,
>>
>>
>>
>> Just a general high-level question about Centurylink/Level3 post-merger,
>> how is your overall experience with CenturyLink? if you could be sitting
>> with the CEO of the company what is one thing you would ask him to fix?
>>
>>
>>
>> please keep it high level and general. i intend to pass these to him and
>> his team in an upcoming meeting.
>>
>>
>>
>> Mehmet
>>
>
>

Re: CenturyLink/Level3 feedback

[Dovid Bender]

For voice there are so many IP options I don't know why anyone even messes
with the old school carriers. About 4 years ago we signed up for L3 VoIP.
We sent calls to France and the callerID didn't make it. We opened a ticket
we were told callerID wasn't guaranteed on international calls. That was
the day we canceled our service and asked for a refund. I am sometimes
amazed how some of these carriers still have customers signing up.



On Wed, Jun 5, 2019 at 8:50 AM Brower, Larry <
larry.bro...@aramcoservices.com> wrote:

> Mehmet,
>
>
>
> Speaking strictly on their voice product, service has gone a bit downhill
> since the merger.
>
>
>
> We never had problems with Level3 before the merger.
>
>
>
> After Centurylink took over we started experiencing problems.
>
>
>
> Just a couple of examples:
>
>
>
> We waited months just to turn up a simple PRI. The PRI was sent back to
> design several times and then when it finally was turned up it isn’t
> working properly. The CL techs who were formally L3 express nothing but
> frustration with dealing with CL following the merger. Complaints to the
> account manager are met with just apologies and delays.
>
>
>
> International call routing has become unreliable. In the last month alone
> we have had to create several service requests related to call failures.
> The result after anywhere from a couple hours to a day is just hey we
> rerouted try again. Then it works for a couple days and back to call
> failures and intercept messages.
>
>
>
> I’ve already been asked if we should drop CenturyLink as the carrier and
> go back to using someone like AT
>
>
>
> Never had any of these issue when it was Level3.
>
>
>
> Regards,
>
>
>
> Larry Brower, CCNP Collaboration, SSCA, RHCSA, CCDA, CCNA
>
> Communications Technician | Unified Communications Group
>
>
>
> Aramco Services Company
>
> *Office:  713.432.4516 | Mobile:  832.570.5416 *
>
> *larry.bro...@aramcoservices.com* 
>
>
> This email has been classified as: *General Use* by *Brower, Larry *on 
> *Wednesday,
> June 5, 2019*
>
>
>
> *From:* NANOG  *On Behalf Of *Mehmet Akcin
> *Sent:* Tuesday, June 4, 2019 9:31 AM
> *To:* nanog 
> *Subject:* CenturyLink/Level3 feedback
>
>
>
> *EXTERNAL: This email came from the Internet. Report this message to
> ascsuspiciousem...@aramcoservices.com
>  as suspicious if it contains any
> suspicious content.*
>
> hi there,
>
>
>
> Just a general high-level question about Centurylink/Level3 post-merger,
> how is your overall experience with CenturyLink? if you could be sitting
> with the CEO of the company what is one thing you would ask him to fix?
>
>
>
> please keep it high level and general. i intend to pass these to him and
> his team in an upcoming meeting.
>
>
>
> Mehmet
>

Re: HE.NET Contact / Outage

[Dovid Bender]

We had an issue in NY as well and they blamed a router in ASH as well. Our
solution was to route away.


On Mon, Jun 3, 2019 at 2:11 PM Jared Geiger  wrote:

> We had a similar issue at 5AM Pacific time in Ashburn VA. They blamed it
> on a software bug and disabled that feature.
>
> We had another outage at the same time a week before also. They blamed it
> on a route table corruption that time.
>
> On Mon, Jun 3, 2019 at 10:06 AM David Deutsch 
> wrote:
>
>> Hi Everyone,
>>
>> We experienced a pretty bad HE.NET  outage on Friday,
>> May 31st where fiber/BGP were up on our side out of LAX and our route
>> advertisements where forwarded to public ASs; however packets stalled
>> midway in the HE network.
>>
>> Urgent calls to their NOC escalating in the morning fell on death ears,
>> with replies like "Senior techs aren't available until later in the day".
>>
>> Can anyone on the list from HE reach out to me directly on the issue
>>
>> Sincerely,
>> David Deutsch
>> Televergence CTO
>> 646-502-4010
>>
>>

Power cut if temps are too high

[Dovid Bender]

  Hi,Is anyone aware of a device that will cut the power if the room goes above X degrees? I am looking for something as a just in case. Regards,Dovid 

Re: BGP prefix filter list

[Dovid Bender]

You have no idea how sad and true this is.

On Wed, May 15, 2019 at 10:16 AM Jon Lewis  wrote:

> On Wed, 15 May 2019, Mike Hammett wrote:
>
> > What is the most common platform people are using with such limitations?
> How long ago was it deprecated?
>
> One network's deprecated router is another network's new [bargain priced]
> core router.  :)
>
> --
>   Jon Lewis, MCP :)   |  I route
>   |  therefore you are
> _ http://www.lewis.org/~jlewis/pgp for PGP public key_
>

Re: Issues with SIP packets between VZ Fios and NTT

[Dovid Bender]

It's not strictly UDP. I spoke with someone yesterday that was re-producing
it with curl.

On Tue, May 14, 2019 at 2:04 AM Saku Ytti  wrote:

> Can someone try to recreate the problem with TCP/5060. Or do iperf
> test on equivalent ports with UDP+TCP, to determine if the problem is
> related specifically to UDP.
>
> Most networks have some form of limits to even transit traffic, UDP is
> most typical L4 to have policers.
>
> On Tue, 14 May 2019 at 00:12, Pete Rohrman 
> wrote:
> >
> > Dovid Bender,
> >
> > I'm seeing the  same sort of thing.  Polycom phones.   Multiple
> customers getting to me from Verizon in NYC area.  I'm seeing phones
> register for a while, then drop off, then I see them trying to re-reg
> resulting in your 401 below.
> >
> > Call me.  212 497 8015.  Let's look at this.
> >
> > Pete
> >
> > Pete Rohrman
> > Stage2 Support
> > 212 497 8000, Opt. 2
> >
> > On 5/13/19 12:20 PM, Dovid Bender wrote:
> >
> > Thought of that. Customers have their own CPE's. So far the only thing
> mutual here is that it's NTT -> VZ. Here is what I found so far looking at
> two Polycom phones using non standard ports (e.g. not 5060)
> > 1) PhoneA tries to register multiple extensions and for each request we
> send a 401. We expect to get back a REGISTER request with a no-once but we
> don't. This happens for a while and then magically it starts working.
> > 2) PhoneB tries to register the time time as PhoneA and has no issues.
> >
> > At first I thought it was something possibly with the SIP call-ID but I
> ruled that out since in the same SIP DIALOG it was not working then it
> started. Also the seems to be per phone each phone is behind NAT and the
> traffic is coming from a different NAT'd port. Seems like there is some
> device in the middle that is randomly dropping traffic on specific sessions.
> >
> >
> >
> >
> >
> > On Mon, May 13, 2019 at 11:40 AM Brielle Bruns  wrote:
> >>
> >> On 5/13/2019 9:21 AM, Dovid Bender wrote:
> >> > Hi,
> >> >
> >> > Over the last 48 hours we have been getting a lot of alerts of
> customers
> >> > phones losing registrations to us. All the complaints are coming from
> >> > customers that are on VZ Fios in the NYC area. Anyone else see
> anything
> >> > strange going on?
> >> >
> >>
> >>
> >> While you are diagnosing, might check to make sure that the SIP ALG is
> >> disabled on all of their routers too.
> >>
> >>
> >>
> >> --
> >> Brielle Bruns
> >> The Summit Open Source Development Group
> >> http://www.sosdg.org/ http://www.ahbl.org
>
>
>
> --
>   ++ytti
>

Re: Issues with SIP packets between VZ Fios and NTT

[Dovid Bender]

In our case we are not using 5060. The issue seems exclusive to VZ.


On Mon, May 13, 2019 at 2:43 PM Jared Mauch  wrote:

> This matches my experience with running SIP on networks. Slowly over the
> years it became more unreliable as “helper” ALGs were in the path.
>
> Eventually we moved some devices off 5060 to alleviate the problem.
>
> Sent from my iCar
>
> On May 13, 2019, at 2:32 PM, Dovid Bender  wrote:
>
> FYI: More than one person reached out to me off list. The issue is clearly
> with VZ. Traces by the others were done and NTT was not in the mix. The
> only common denominator was 401 SIP packets hitting VZ Fios IP's in the NY
> area.
>
>
>
> On Mon, May 13, 2019 at 1:04 PM Dovid Bender  wrote:
>
>> Good ol UDP encrypted.
>>
>>
>>
>> On Mon, May 13, 2019 at 12:49 PM Brielle Bruns  wrote:
>>
>>>
>>> On 5/13/2019 10:20 AM, Dovid Bender wrote:
>>> > Thought of that. Customers have their own CPE's. So far the only thing
>>> > mutual here is that it's NTT -> VZ. Here is what I found so far
>>> looking
>>> > at two Polycom phones using non standard ports (e.g. not 5060)
>>> > 1) PhoneA tries to register multiple extensions and for each request
>>> we
>>> > send a 401. We expect to get back a REGISTER request with a no-once
>>> but
>>> > we don't. This happens for a while and then magically it starts
>>> working.
>>> > 2) PhoneB tries to register the time time as PhoneA and has no issues.
>>> >
>>> > At first I thought it was something possibly with the SIP call-ID but
>>> I
>>> > ruled that out since in the same SIP DIALOG it was not working then it
>>> > started. Also the seems to be per phone each phone is behind NAT and
>>> the
>>> > traffic is coming from a different NAT'd port. Seems like there is
>>> some
>>> > device in the middle that is randomly dropping traffic on specific
>>> sessions.
>>>
>>>
>>> Are you using TLS encrypted SIP or just plain ol' cleartext?
>>>
>>> If its encrypted, I'd look at possibly there being a MTU/MSS issue
>>> somewhere along the path possibly?
>>>
>>>
>>> --
>>> Brielle Bruns
>>> The Summit Open Source Development Group
>>> http://www.sosdg.org/ http://www.ahbl.org
>>>
>>

Re: Issues with SIP packets between VZ Fios and NTT

[Dovid Bender]

FYI: More than one person reached out to me off list. The issue is clearly
with VZ. Traces by the others were done and NTT was not in the mix. The
only common denominator was 401 SIP packets hitting VZ Fios IP's in the NY
area.



On Mon, May 13, 2019 at 1:04 PM Dovid Bender  wrote:

> Good ol UDP encrypted.
>
>
>
> On Mon, May 13, 2019 at 12:49 PM Brielle Bruns  wrote:
>
>>
>> On 5/13/2019 10:20 AM, Dovid Bender wrote:
>> > Thought of that. Customers have their own CPE's. So far the only thing
>> > mutual here is that it's NTT -> VZ. Here is what I found so far looking
>> > at two Polycom phones using non standard ports (e.g. not 5060)
>> > 1) PhoneA tries to register multiple extensions and for each request we
>> > send a 401. We expect to get back a REGISTER request with a no-once but
>> > we don't. This happens for a while and then magically it starts working.
>> > 2) PhoneB tries to register the time time as PhoneA and has no issues.
>> >
>> > At first I thought it was something possibly with the SIP call-ID but I
>> > ruled that out since in the same SIP DIALOG it was not working then it
>> > started. Also the seems to be per phone each phone is behind NAT and
>> the
>> > traffic is coming from a different NAT'd port. Seems like there is some
>> > device in the middle that is randomly dropping traffic on specific
>> sessions.
>>
>>
>> Are you using TLS encrypted SIP or just plain ol' cleartext?
>>
>> If its encrypted, I'd look at possibly there being a MTU/MSS issue
>> somewhere along the path possibly?
>>
>>
>> --
>> Brielle Bruns
>> The Summit Open Source Development Group
>> http://www.sosdg.org/ http://www.ahbl.org
>>
>

Re: Issues with SIP packets between VZ Fios and NTT

[Dovid Bender]

Good ol UDP encrypted.



On Mon, May 13, 2019 at 12:49 PM Brielle Bruns  wrote:

>
> On 5/13/2019 10:20 AM, Dovid Bender wrote:
> > Thought of that. Customers have their own CPE's. So far the only thing
> > mutual here is that it's NTT -> VZ. Here is what I found so far looking
> > at two Polycom phones using non standard ports (e.g. not 5060)
> > 1) PhoneA tries to register multiple extensions and for each request we
> > send a 401. We expect to get back a REGISTER request with a no-once but
> > we don't. This happens for a while and then magically it starts working.
> > 2) PhoneB tries to register the time time as PhoneA and has no issues.
> >
> > At first I thought it was something possibly with the SIP call-ID but I
> > ruled that out since in the same SIP DIALOG it was not working then it
> > started. Also the seems to be per phone each phone is behind NAT and the
> > traffic is coming from a different NAT'd port. Seems like there is some
> > device in the middle that is randomly dropping traffic on specific
> sessions.
>
>
> Are you using TLS encrypted SIP or just plain ol' cleartext?
>
> If its encrypted, I'd look at possibly there being a MTU/MSS issue
> somewhere along the path possibly?
>
>
> --
> Brielle Bruns
> The Summit Open Source Development Group
> http://www.sosdg.org/ http://www.ahbl.org
>

Re: Issues with SIP packets between VZ Fios and NTT

[Dovid Bender]

Thought of that. Customers have their own CPE's. So far the only thing
mutual here is that it's NTT -> VZ. Here is what I found so far looking at
two Polycom phones using non standard ports (e.g. not 5060)
1) PhoneA tries to register multiple extensions and for each request we
send a 401. We expect to get back a REGISTER request with a no-once but we
don't. This happens for a while and then magically it starts working.
2) PhoneB tries to register the time time as PhoneA and has no issues.

At first I thought it was something possibly with the SIP call-ID but I
ruled that out since in the same SIP DIALOG it was not working then it
started. Also the seems to be per phone each phone is behind NAT and the
traffic is coming from a different NAT'd port. Seems like there is some
device in the middle that is randomly dropping traffic on specific sessions.





On Mon, May 13, 2019 at 11:40 AM Brielle Bruns  wrote:

> On 5/13/2019 9:21 AM, Dovid Bender wrote:
> > Hi,
> >
> > Over the last 48 hours we have been getting a lot of alerts of customers
> > phones losing registrations to us. All the complaints are coming from
> > customers that are on VZ Fios in the NYC area. Anyone else see anything
> > strange going on?
> >
>
>
> While you are diagnosing, might check to make sure that the SIP ALG is
> disabled on all of their routers too.
>
>
>
> --
> Brielle Bruns
> The Summit Open Source Development Group
> http://www.sosdg.org/ http://www.ahbl.org
>

Issues with SIP packets between VZ Fios and NTT

[Dovid Bender]

Hi,

Over the last 48 hours we have been getting a lot of alerts of customers
phones losing registrations to us. All the complaints are coming from
customers that are on VZ Fios in the NYC area. Anyone else see anything
strange going on?

TIA.

Dovid

Re: Routing issues to AWS environment.

[Dovid Bender]

Interesting at my 9-5 we use NTT exclusively for SIP traffic and it has
been flawless. If there are any tests that you want me to run over NTT via
their pop at 111 8th let me know.


On Thu, May 9, 2019 at 6:35 AM Chuck Church  wrote:

> Are you sure the problem isn’t NTT?  My buddy’s WISP peers with Spirit and
> had a boatload of problems with random packet loss affecting initially just
> SIP and RTP (both UDP).  Spirit was blaming NTT.  Problems went away when
> Spirit stopped peering with NTT yesterday.  Path is through Telia now to
> their main SIP trunk provider.
>
>
>
> chuck
>
>
>
> *From:* NANOG  *On Behalf Of *Curt Rice
> *Sent:* Wednesday, May 08, 2019 10:56 AM
> *To:* nanog@nanog.org
> *Subject:* Routing issues to AWS environment.
>
>
>
> Hi are there any AWS engineers out there? We are seeing routing problems
> between NTT and AWS in Ashburn, Va and would like to find out which side is
> having the problem.
>
>
>
> Thanks,
>
> Curt
>
>

Re: OffTopic: Telecom Fraud

[Dovid Bender]

On Tue, Apr 23, 2019 at 4:18 PM Paul Timmins  wrote:

> I guarantee you that if carriers were made civilly or criminally liable
> for allowing robodialers to operate on their network, this sort of issue
> would end practically overnight. Robodialer calling patterns are
> obvious, and I'd imagine any tech could give you a criteria to search
> for in the CDR streams to identify them and shut them off in hours.
>
> Problem is, they're lucrative to provide services to, and there is
> immunity on the carrier's part to these sorts of issues. SHAKEN/STIR
> nonwithstanding (I don't think we'll see widespread adoption of this
> within a decade, even with a government mandate as there's still a
> massive embedded base of switches that can't support it and never will).
>
> It may be incredibly frustrating, but there's plenty of money to be made
> in prolonging the problem.
>
>
That was my thought as well. From what I heard last 50% of the calls are
fraud. That's a lot of money that they are collecting on origination. I
also saw this
https://www.multichannel.com/news/comcast-and-att-test-anti-robocalling-tech
and
did  a test. A client owned a Comcast number and had ATT. I set the CLI to
the Comcast number and it showed up on the ATT phone as I set it. You would
think if ATT had the tools in place at the very least it wouldn't display
the number.

OffTopic: Telecom Fraud

[Dovid Bender]

Hi All,

I am wondering if a bit of public shaming may help. I every so often get
calls from the "verizon wireless fraud prevention dept". It's scammers
calling me (and others) telling them there was fraud on their account. This
gets people worked up and fooled into giving out data that they normally
wouldn't. This allows the fraudsters to then order devices under the
victims name. They spoof their caller ID to that of Verizons. I understand
there is currently no fix (though lets hope that SHAKEN/STIR fixes it one
day). but at the very least why can't Verizon drop these calls at their
edge. If they see the B-Number as being their client and the A number being
theirs but coming from elsewhere why can't they just drop the call?

If anyone has any insight I would love to hear it.

TIA.

Regards,

Dovid

Re: Facebook outage

[Dovid Bender]

That should have read FB not DB.

On Sun, Apr 14, 2019, 07:41 Dovid Bender  wrote:

> It's all over Twitter. DB, What's app and Instagram are all having issues.
>
> On Sun, Apr 14, 2019, 07:32 Siyuan Miao  wrote:
>
>> Dear community,
>>
>> It seems that Facebook network is partially down.
>>
>> Here's a traceroute from some locations to fbcdn Hong Kong
>> (157.240.15.37):
>>
>>  Host
>>Loss%   Snt   Last   Avg  Best  Wrst StDev
>>  1. ???
>>  2. fra-in8-01sw.voxility.net
>> 0.6%   1810.5   0.6   0.4   4.9   0.5
>>  3. fra-in8-01c.voxility.net
>>  0.0%   181   14.7   3.7   0.3  44.1   8.5
>>  4. fra-in3-02gw.voxility.net
>> 0.0%   1810.9   3.5   0.7 195.2  14.5
>>  5. fra-eq5-02gw.voxility.net
>> 0.0%   1810.6   0.5   0.3   0.7   0.0
>>  6. fra-eq5-03gw.voxility.net
>> 0.0%   1810.6   0.7   0.4   6.6   0.7
>>  7. ae10.pr02.fra5.tfbnw.net
>>  0.0%   1811.2   3.5   0.8  35.0   5.2
>>  8. ???
>>  9. ae121.ar03.fra2.tfbnw.net
>> 0.0%   1814.4   2.1   1.0  21.1   2.2
>> 10. ae32.bb02.fra2.tfbnw.net
>>  0.0%   1815.1   4.6   1.4  14.0   2.7
>> 11. ae15.bb03.odn2.tfbnw.net
>>  0.0%   181   19.2  19.8  18.5  26.3   1.2
>> 12. ae12.dr03.odn2.tfbnw.net
>> 92.8%   181   27.8  24.4  18.3  43.4   8.4
>> 13. ???
>>
>>  Host
>>Loss%   Snt   Last   Avg  Best  Wrst StDev
>>  1. lax-cs1-02sw.voxility.net
>> 0.0%   1940.3   2.5   0.2  36.9   5.1
>>  2. lax-cs1-01c.voxility.net
>>  0.0%   1946.1   2.8   0.2  47.3   6.4
>>  3. lax-cs1-02gw.voxility.net
>> 0.0%   1940.2   0.1   0.1   0.3   0.0
>>  4. ce-0-13-0-1.r00.lsanca07.us.bb.gin.ntt.net
>>  0.0%   1940.9   0.5   0.4   1.0   0.0
>>  5. ae-3.r01.lsanca07.us.bb.gin.ntt.net
>> 0.0%   1940.5   0.5   0.4   0.9   0.0
>>  6. ae-0.tata-communications.lsanca07.us.bb.gin.ntt.net
>> 0.0%   1940.7   1.0   0.4  28.8   2.8
>>  7. if-et-20-2.hcore2.kv8-chiba.as6453.net
>>  0.0%   194  158.6 158.8 158.4 175.5   1.8
>>  8. if-et-1-2.hcore1.kv8-chiba.as6453.net
>> 0.0%   194  152.7 152.8 152.5 155.8   0.2
>>  9. if-ae-16-2.tcore1.hk2-hong-kong.as6453.net
>>  0.0%   194  162.1 163.0 162.0 213.5   4.9
>> 10. ???
>>
>> What do you think ?
>>
>>

Re: Facebook outage

[Dovid Bender]

It's all over Twitter. DB, What's app and Instagram are all having issues.

On Sun, Apr 14, 2019, 07:32 Siyuan Miao  wrote:

> Dear community,
>
> It seems that Facebook network is partially down.
>
> Here's a traceroute from some locations to fbcdn Hong Kong (157.240.15.37):
>
>  Host
>  Loss%   Snt   Last   Avg  Best  Wrst StDev
>  1. ???
>  2. fra-in8-01sw.voxility.net
> 0.6%   1810.5   0.6   0.4   4.9   0.5
>  3. fra-in8-01c.voxility.net
>0.0%   181   14.7   3.7   0.3  44.1   8.5
>  4. fra-in3-02gw.voxility.net
> 0.0%   1810.9   3.5   0.7 195.2  14.5
>  5. fra-eq5-02gw.voxility.net
> 0.0%   1810.6   0.5   0.3   0.7   0.0
>  6. fra-eq5-03gw.voxility.net
> 0.0%   1810.6   0.7   0.4   6.6   0.7
>  7. ae10.pr02.fra5.tfbnw.net
>0.0%   1811.2   3.5   0.8  35.0   5.2
>  8. ???
>  9. ae121.ar03.fra2.tfbnw.net
> 0.0%   1814.4   2.1   1.0  21.1   2.2
> 10. ae32.bb02.fra2.tfbnw.net
>0.0%   1815.1   4.6   1.4  14.0   2.7
> 11. ae15.bb03.odn2.tfbnw.net
>0.0%   181   19.2  19.8  18.5  26.3   1.2
> 12. ae12.dr03.odn2.tfbnw.net
>   92.8%   181   27.8  24.4  18.3  43.4   8.4
> 13. ???
>
>  Host
>  Loss%   Snt   Last   Avg  Best  Wrst StDev
>  1. lax-cs1-02sw.voxility.net
> 0.0%   1940.3   2.5   0.2  36.9   5.1
>  2. lax-cs1-01c.voxility.net
>0.0%   1946.1   2.8   0.2  47.3   6.4
>  3. lax-cs1-02gw.voxility.net
> 0.0%   1940.2   0.1   0.1   0.3   0.0
>  4. ce-0-13-0-1.r00.lsanca07.us.bb.gin.ntt.net
>0.0%   1940.9   0.5   0.4   1.0   0.0
>  5. ae-3.r01.lsanca07.us.bb.gin.ntt.net
> 0.0%   1940.5   0.5   0.4   0.9   0.0
>  6. ae-0.tata-communications.lsanca07.us.bb.gin.ntt.net
> 0.0%   1940.7   1.0   0.4  28.8   2.8
>  7. if-et-20-2.hcore2.kv8-chiba.as6453.net
>0.0%   194  158.6 158.8 158.4 175.5   1.8
>  8. if-et-1-2.hcore1.kv8-chiba.as6453.net
> 0.0%   194  152.7 152.8 152.5 155.8   0.2
>  9. if-ae-16-2.tcore1.hk2-hong-kong.as6453.net
>0.0%   194  162.1 163.0 162.0 213.5   4.9
> 10. ???
>
> What do you think ?
>
>

Re: Gi Firewall for mobile subscribers

[Dovid Bender]

I don't v6 stats yet but it would be interesting to see. I did a tcpdump on
one v6 IP and saw hundreds of requests to port 25.


On Wed, Apr 10, 2019 at 10:43 AM Ca By  wrote:

>
>
> On Wed, Apr 10, 2019 at 7:06 AM Dovid Bender  wrote:
>
>> I think the traffic Amos is referring to is random traffic hitting the
>> devices causing them to "wake up". Everyone here knows a simple dump on
>> port 22 will show traffic. We  have a /22 that gets an avg of 1-2 mbit of
>> random traffic (mainly 22 and 3389).
>>
>
> I believe he was talking about ipv6.
>
> Does this backscatter happen in ipv6 given how impractical scanning ipv6
> is ?
>
>
>
>> On Wed, Apr 10, 2019 at 9:49 AM Ca By  wrote:
>>
>>>
>>>
>>> On Wed, Apr 10, 2019 at 6:23 AM Amos Rosenboim 
>>> wrote:
>>>
>>>> Hello NANOG,
>>>>
>>>>
>>>>
>>>> We are discussing internally and wanted to get more opinions and
>>>> especially more data on what are people actually doing.
>>>>
>>>> We are running an ISP network with about 150K fixed broadband users,
>>>> running dual stack (IPv4 behind CGNAT).
>>>>
>>>> On the ISP network  IPv6 is simply routed, and is firewalled on the CPE.
>>>>
>>>>
>>>>
>>>> This network added mobile services about a year ago, also dual stack
>>>> (we have no control on the mobile devices so we were too concerned to
>>>> choose IPv6 only access).
>>>>
>>>> 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.
>>>>
>>>>
>>>>
>>>> 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.
>>>>
>>>>
>>>>
>>>> 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 ?
>>>>
>>>>
>>>>
>>>> BTW – I don’t mention IPv4 traffic on the mobile network as it’s all
>>>> behind CGNAT which don’t allow internet initiated connections.
>>>>
>>>>
>>>>
>>>> Anyway, we are very interested to know hear more opinions,  and
>>>> especially to hear what are other mobile operators do.
>>>>
>>>>
>>>>
>>>> Regards
>>>>
>>>>
>>>>
>>>> Amos
>>>>
>>>>
>>>>
>>>
>>> Step outside the theoretical and model your real threats. Attack
>>> yourself of pay someone to do a real pentest.
>>>
>>> 1. Does a hacker know the ipv6 of your subs? How frequently does the sub
>>> get a new 128 bit address?
>>>
>>> 2.  What does the hacker get from a paging storm?  Economic benefit ?
>>> Lolz? Has a malicious paging storm ever happened in the real world?  What
>>> level of effort would be required to trigger that?  Is that level of effort
>>> more or less than it would take to tip over a stateful firewall (session
>>> exhaustion, pps attack, alg bugs, vulns in the fw
>>>
>>> https://www.zdnet.com/article/cisco-removed-its-seventh-backdoor-account-this-year-and-thats-a-good-thing/
>>> )
>>>
>>> 3. Assuming the hacker gleans the address of the sub, what ports are
>>> open in the real world? What can a hacker connect to and accomplish?
>>>
>>>
>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>

SNMP via proxy

[Dovid Bender]

Hi,

A bit off topic. One of my early mistakes in my 9-5 was hard coding the
IP's of our SNMP box in all of our gear (networking equipment, Servers
etc,). The box is at its limit and increasing its capacity will be
nearly impossible. We mainly use Nagios and Cacti to monitor our network.
Going forward I was thinking of setting up a few hosts whose job would be
to simply relay SNMP traffic. This way moving forward we could hard code
several IP's and bounce all traffic through one of these IP's.

TIA for your advice.

Regards,

Dovid

Re: Gi Firewall for mobile subscribers

[Dovid Bender]

I think the traffic Amos is referring to is random traffic hitting the
devices causing them to "wake up". Everyone here knows a simple dump on
port 22 will show traffic. We  have a /22 that gets an avg of 1-2 mbit of
random traffic (mainly 22 and 3389).

On Wed, Apr 10, 2019 at 9:49 AM Ca By  wrote:

>
>
> On Wed, Apr 10, 2019 at 6:23 AM Amos Rosenboim 
> wrote:
>
>> Hello NANOG,
>>
>>
>>
>> We are discussing internally and wanted to get more opinions and
>> especially more data on what are people actually doing.
>>
>> We are running an ISP network with about 150K fixed broadband users,
>> running dual stack (IPv4 behind CGNAT).
>>
>> On the ISP network  IPv6 is simply routed, and is firewalled on the CPE.
>>
>>
>>
>> This network added mobile services about a year ago, also dual stack (we
>> have no control on the mobile devices so we were too concerned to choose
>> IPv6 only access).
>>
>> 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.
>>
>>
>>
>> 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.
>>
>>
>>
>> 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 ?
>>
>>
>>
>> BTW – I don’t mention IPv4 traffic on the mobile network as it’s all
>> behind CGNAT which don’t allow internet initiated connections.
>>
>>
>>
>> Anyway, we are very interested to know hear more opinions,  and
>> especially to hear what are other mobile operators do.
>>
>>
>>
>> Regards
>>
>>
>>
>> Amos
>>
>>
>>
>
> Step outside the theoretical and model your real threats. Attack yourself
> of pay someone to do a real pentest.
>
> 1. Does a hacker know the ipv6 of your subs? How frequently does the sub
> get a new 128 bit address?
>
> 2.  What does the hacker get from a paging storm?  Economic benefit ?
> Lolz? Has a malicious paging storm ever happened in the real world?  What
> level of effort would be required to trigger that?  Is that level of effort
> more or less than it would take to tip over a stateful firewall (session
> exhaustion, pps attack, alg bugs, vulns in the fw
>
> https://www.zdnet.com/article/cisco-removed-its-seventh-backdoor-account-this-year-and-thats-a-good-thing/
> )
>
> 3. Assuming the hacker gleans the address of the sub, what ports are open
> in the real world? What can a hacker connect to and accomplish?
>
>
>
>>
>>
>>
>>
>>
>

Re: Contacts wanted: OVH, DigitalOcean, and Microsoft (Deutschland)

[Dovid Bender]

Two notes:
1) We have seen most of the telecom fraud happen from three general
locations
a. The phones themselves. For instance people putting phones out there with
the default password.
b. Compromised routers. Fraudsters will compromise a CPE and bounce their
traffic through it. Back in the day when we banned Palestine most of the
fraud went down. Once they caught on they realized the traffic needed to
flow from anywhere but PS.
c. OVH - We used to get a lot from there till we started banning large
blocks of their ranges. It seems the fraudsters caught on and they are
going the route of compromised CPE's.

2) I spoke a few years back with the lead network engineers at DO and
without giving away too much they are very aware that people use their
network for fraud and actively work against it. I am nor sure about their
abuse team but I know their core engineers have methods in place and shut
down malicious activity. The issue is it's easier said then done.



On Mon, Mar 18, 2019 at 8:03 PM Ronald F. Guilmette 
wrote:

>
> OVH, DigitalOcean, and Microsoft...
>
> Is there anybody awake and conscious at any of these places?  I mean
> anybody who someone such as myself... just part of the Great Unwashed
> Masses... could actually speak to about a real and ongoing problem?
>
> Maybe most of you here will think that this is just a trivial problem, and
> one that's not even worth mentioning on NANOG.  So be it. Make up you own
> minds.  Here is the problem...
>
> For some time now, there has been an ongoing campaign of bitcoin
> extortion spamming going on which originates primarily or perhaps
> exclusively from IPv4 addresses owned by OVH and DigitalOcean.
> These scam spams have now been publicised in multiple places:
>
>https://myonlinesecurity.co.uk/fake-cia-sextortion-scam/
>
> Yea, that's just one place, I know, but there's also no shortage of people
> tweeting about this crap also, in multiple languages even!
>
> https://twitter.com/SpamAuditor/status/1107365604636278784
> https://twitter.com/dvk01uk/status/1107510553621266433
> https://twitter.com/bortzmeyer/status/1107737034049900544
> https://twitter.com/ariestess69/status/1107468838596038656
> https://twitter.com/bernhard_mahr/status/1107513313020297216
> https://twitter.com/jzmurdock/status/1107679858945974272
> https://twitter.com/gamamb/status/1107384186548207617
> https://twitter.com/davidgsIoT/status/1107725201331097606
> https://twitter.com/cybers_guards/status/1107675396076560384
> https://twitter.com/ThatHostingCo/status/1107588660831105024
> https://twitter.com/fladna9/status/1107554090765242368
> https://twitter.com/JUSTADACHI/status/1107549777607184384
> https://twitter.com/okhin/status/1107627379650908160
> https://twitter.com/Purple_Wyrm/status/1107454618705887232
> https://twitter.com/LadyOFyre/status/110734900550144
> https://twitter.com/laurelvail/status/1107345980062523392
> https://twitter.com/Alex__Rubio/status/1107595560440217600
>
> The thing of it is that ALL of this crap... al of these scam spams... are
> quite obviously originating out of the networks of OVH and DigitalOcean.
> And it's not even all that hard to figure out where from, exactly and
> specifically.  I generated the following survey, on the fly, last night,
> based on a simple reverse DNS scan of the evidently relevant addrdess
> ranges:
>
> https://pastebin.com/raw/WtM0Y5yC
>
> As anyone who isn't as blind as a bat can easily see, there's a bit of a
> pattern here.  All of the spam source IPs are on just two ASNs:
>
>AS16276 - OVH SAS
>AS4061 - DigitalOcean, LLC
>
> It's equally clear that there have already been numerous reports about this
> ongoing and blatantly criminal activity that have been sent to the
> low-level
> high school dropout interns that these companies, like most others on the
> Internet these days, choose to employ as their first-level minions in their
> "not a profit center" abuse handling departments.  So, guess what?
> Surprise,
> surprise!  None of those clue-deprived flunkies have apparently yet managed
> to figure out that there's a pattern here.  Duh!.  As a result, the
> scamming
> and the spamming just go on and on and on, and the spammer-scammer just
> keeps on getting fresh new IP addresess on both of these networks... and
> fresh (and utterly free) new domain names from the equally careless company
> called Freenom.
>
> So, you know, I really would appreciate it if someone could either put me
> in touch with some actual sentient being at either OVH or DigitalOcean...
> assuming that any such actually exist... or at the very least, try to find
> one to whom clue may be passed about all this, because although these scam
> spams were kind of humorous and novel at first, the novelty has now worn
> off
> and they're really not all that funny anymore.
>
> Oh!   And while we are on the subject, I'd also like to obtain a contact,
> preferbly one which is 

Re: Cellular backup connections

[Dovid Bender]

Anyone know if Verizon static IP's over LTE have same issue where they
bounce the traffic around before it gets back to the NY metro area?



On Thu, Jan 3, 2019 at 6:46 PM Dovid Bender  wrote:

> All,
>
> Thanks for all of the feedback. I was on site today and noticed two things.
> 1) As someone mentioned it could be for static IP's they have the traffic
> going to a specific location. The POP is in NJ there was a min. latency of
> 120ms which prob had to do with this.
> 2) I was watching the ping times and it looked something like this:
> 400ms
> 360ms
> 330ms
> 300ms
> 260ms
> 210ms
> 170ms
> 140ms
> 120ms
> 400ms
> 375ms
>
> It seems to have been coming in "waves". I assume this has to do with "how
> cellular work" and the signal. I tried moving it around by putting it down
> low on the floor, moving it locations etc. and saw the same thing every
> time. I am going to try Verizon next and see how it goes.
>
>
>
> On Sat, Dec 29, 2018 at 12:13 PM Mark Milhollan  wrote:
>
>> On Fri, 28 Dec 2018, Dovid Bender wrote:
>>
>> >I finally got around to setting up a cellular backup device in our new
>> POP.
>>
>> >When SSH'ing in remotely the connection seems rather slow.
>>
>> Perhaps using MOSH can help make the interactive CLI session less
>> annoying.
>>
>> >Verizon they charge $500.00 just to get a public IP and I want to avoid
>> >that if possible.
>>
>> You might look into have it call out / maintain a connection back to
>> your infrastructure.
>>
>>
>> /mark
>>
>

Re: Cellular backup connections

[Dovid Bender]

All,

Thanks for all of the feedback. I was on site today and noticed two things.
1) As someone mentioned it could be for static IP's they have the traffic
going to a specific location. The POP is in NJ there was a min. latency of
120ms which prob had to do with this.
2) I was watching the ping times and it looked something like this:
400ms
360ms
330ms
300ms
260ms
210ms
170ms
140ms
120ms
400ms
375ms

It seems to have been coming in "waves". I assume this has to do with "how
cellular work" and the signal. I tried moving it around by putting it down
low on the floor, moving it locations etc. and saw the same thing every
time. I am going to try Verizon next and see how it goes.



On Sat, Dec 29, 2018 at 12:13 PM Mark Milhollan  wrote:

> On Fri, 28 Dec 2018, Dovid Bender wrote:
>
> >I finally got around to setting up a cellular backup device in our new
> POP.
>
> >When SSH'ing in remotely the connection seems rather slow.
>
> Perhaps using MOSH can help make the interactive CLI session less
> annoying.
>
> >Verizon they charge $500.00 just to get a public IP and I want to avoid
> >that if possible.
>
> You might look into have it call out / maintain a connection back to
> your infrastructure.
>
>
> /mark
>

Re: Cellular backup connections

[Dovid Bender]

It's strange. When we use T-Mo on an andriod device the ping times are
30-40 ms. When we try with the modem + raritn console box it jumps to min
of 100+ ms (the modem is high up on top of the rack and we test with the
phones we are on the floor) - Can 5 feet higher make it that much worse?


On Fri, Dec 28, 2018 at 7:23 AM Brandon Martin 
wrote:

> On 12/28/18 7:06 AM, Dovid Bender wrote:
> > Hi All,
> >
> > I finally got around to setting up a cellular backup device in our new
> > POP. I am currently testing with T-Mobile where the cell signal strength
> > is at 80%. The connection is 4G. When SSH'ing in remotely the connection
> > seems rather slow. Ping times seem to be all over the place (for
> > instance now I am seeing: rtt min/avg/max/mdev =
> > 174.142/336.792/555.574/99.599 ms) . Is that just cellular or is that
> > more related to the provider and the location where I am? I could in
> > theory test with VZ and ATT as well. With Verizon they charge $500.00
> > just to get a public IP and I want to avoid that if possible.
> >
> > Thanks and sorry in advance if this is off topic.
>
> LTE with a good connection on a lightly loaded cell should be
> significantly less than that in both absolute terms as well as jitter.
>
> I used LTE (Sprint) for a couple years as my primary connectivity when I
> moved out into an area with zero connectivity (fixing that now).  I
> typically saw ~30-40ms to Chicago, which is the nearest major carrier
> PoP.  Jitter was typically less than 10ms.  VoIP was usable.  Others in
> the area on other carriers have reported similar.
>
> Sprint gave me a public IP with no up front charges but did charge $5/mo
> for it.
>
> As you're probably aware, the "signal strength" ("bars") indicators that
> are presented to the consumer-facing interfaces are often very cooked.
> Depending on which RSSI you're looking at, a "very good" signal is
> probably in the realm of -70dBm to -110dBm (note that there are two RSSI
> metrics commonly used with LTE, and they tend to differ by ~20dB).
>
> --
> Brandon Martin
>

Cellular backup connections

[Dovid Bender]

Hi All,

I finally got around to setting up a cellular backup device in our new POP.
I am currently testing with T-Mobile where the cell signal strength is at
80%. The connection is 4G. When SSH'ing in remotely the connection seems
rather slow. Ping times seem to be all over the place (for instance now I
am seeing: rtt min/avg/max/mdev = 174.142/336.792/555.574/99.599 ms) . Is
that just cellular or is that more related to the provider and the location
where I am? I could in theory test with VZ and ATT as well. With Verizon
they charge $500.00 just to get a public IP and I want to avoid that if
possible.

Thanks and sorry in advance if this is off topic.

Re: Monitoring service that has a human component?

[Dovid Bender]

For my 9-5 we have a company that has a 24/7 NOC that watches all of our
boxes. They CEO is in the US and the NOC guys are seas. They are generally
very responsive. It's very affordable (about $200.00 per box per month).
These guys work real well but they are sort of work in the Box. We need to
give them guidelines. For example we do telecom and clients get hit with
fraud all the time. There are times where we know it's 90% fraud and we
want them to shut it down, there are times where there is a 50/50 chance
that it's fraud. If the system thinks there is a 90% chance it emails them
"Fraud call from X to Y". They then have a procedure on how to figure out
based on the call record who the client is and they shut them down. If it's
the 50/50 chance they get an alert "POSSIBLE Fraudulent call from X to Y".
For such a call they have to go through a series of checks before they shut
them down. What I am getting at is they aren't good at figuring out what is
fraud but are very good at following rules and doing exactly what you ask
of them. What ever technology we use they learn it (be it OpenSips,
Asterisk etc.). We do need to tell them exactly what to monitor and what to
do for specific alarms.

If you want an intro let me know.


On Wed, Dec 5, 2018 at 5:40 PM John Von Essen  wrote:

> Whats your budget?
>
> The outsourced NOC firms tend to be expensive (I've looked at them for a
> project), and they are also not that fast, so dont expect someone to
> determine if an alarm is valid within a few minutes, instead, in goes into
> their queue and waits for a tech to pick it up, so it could be 30-60 mins.
>
> In a perfect scenario, using freelancer/gig-economy people should be able
> to get this done quickly, but its needs to be sizeable to start and will
> involve alot of logistics, which means money.
>
> To be honest, the best option may be to hire a developer to custom code
> really good logic that eliminates a good deal of the false positives so
> only a handful make it through.
> -John
>
> On 12/5/18 5:01 PM, David H wrote:
>
> Hey all, was curious if anyone knows of a website monitoring service that
> has the option to incorporate a human component into the decision and
> escalation tree?  I’m trying to help a customer find a way around false
> positives bogging down their NOC staff, by having a human determine the
> difference between a real error, desired (but different) content, or
> something in between like “Hey it’s 3am and we’ve taken our website offline
> for maintenance, we’ll be back up by 6am.”  Automated systems tend to only
> know if test A, or steps A through C, are failing, then this is ‘down’ and
> do my preconfigured thing, but that ends up needlessly taking NOC time if
> the customer themselves is performing work on their own site, or just
> changed it and whatever content was being watched, is now gone.  So, the
> goal would be to have the end user be the first point of contact if it
> looks like more of a customer-side issue.  If they can’t be reached to
> confirm, THEN contact NOC, and unlike email alerts, keep contacting until a
> human acknowledges receipt of the alert.
>
>
>
> Thanks
>
>

Zayo vs Coent

[Dovid Bender]

Hi,

We are in a facility where my only options are Cogent or Zayo. We plan on
getting a 10G connection for a web crawler using v4 only. Looking for
feedback on either or (keeping the politics out of it).

TIA.

Dovid

Re: Cogent charging 50/mo for BGP (not IPs, the service)

[Dovid Bender]

Here in the US it is unheard of. So far for every turn up I have done in
Europe or Asia we were charged a separate BGP session fee.


On Fri, Oct 19, 2018 at 9:17 AM, Jeff Waddell <
jeff+na...@waddellsolutions.com> wrote:

> What Cogent charges is not a one time fee, its monthly recurring
>
> On Fri, Oct 19, 2018 at 8:43 AM H I Baysal  wrote:
>
>> Indeed, its a one time fee to setup BGP. And as a side note,
>> I's also separate for v4 and v6 sessions.
>>
>> I was also taken aback when i heard it the first time.
>> On 17-10-18 18:12, David Hubbard wrote:
>>
>> They charge it even if you’re using your own address space.  It’s a fee
>> simply for establishing BGP with them on a given circuit.  I believe if you
>> used static routes and their space, you would not have to pay it.
>>
>>
>>
>> *From: *NANOG   on
>> behalf of Josh Luthman 
>> 
>> *Date: *Wednesday, October 17, 2018 at 12:10 PM
>> *To: *Brielle Bruns  
>> *Cc: *NANOG list  
>> *Subject: *Re: Cogent charging 50/mo for BGP (not IPs, the service)
>>
>>
>>
>> I view Cogent IP space as a way to lock customers to their service, ie
>> make them sticky.
>>
>> Josh Luthman
>> Office: 937-552-2340
>> Direct: 937-552-2343
>> 1100 Wayne St
>> 
>> Suite 1337
>> Troy, OH 45373
>>
>>
>>
>> On Wed, Oct 17, 2018, 12:03 PM Brielle Bruns  wrote:
>>
>> On 10/17/2018 9:47 AM, Josh Luthman wrote:
>> > Has anyone else dealt with this mess?  Even my Cogent rep admits it's
>> > unique to their business.
>>
>> That sounds like the BS the first company I worked for tried to pull.
>>
>> One would think they'd welcome customers bringing their own IP space
>> since it saves them money by not using up precious Cogent IPv4 address
>> space.
>>
>> Hell, I even have BGP for v4 and v6 over my CenturyLink biz fiber, and
>> its available as part of the enhanced package they offer with no extra
>> fees.
>>
>>
>> --
>> Brielle Bruns
>> The Summit Open Source Development Group
>> http://www.sosdg.org/ http://www.ahbl.org
>>
>>

Re: Whats going on at Cogent

[Dovid Bender]

We have been very happy with HE. It was a no brainer over cogent. They are
smaller (so are we). When there are issues they are real fast to fix them,
you also get the personal touch which you don't get with others.


On Tue, Oct 16, 2018 at 10:10 AM, Eric Dugas 
wrote:

> I don't really get the Cogent/Google peering issues. I've been hearing
> this for years... How about fixing it already? Telling customer to get
> other transit providers to get to a given network is really bad.
>
> On a side note, HE is still HE but they're trying really hard to be a good
> netcitizen. They've finally pushed filtering for peers:
> http://routing.he.net. I wouldn't get transit from them, but in some
> markets, they're the only affordable IP transit providers.
>
> On Oct 16 2018, at 10:04 am, DaKnOb  wrote:
>
>
>
> When I call and mention it I’m told that it’s HE’s fault (despite the
> lovely cake), but when I also bring Google, then they tell me to get a
> different provider just for this traffic, or meet them at an IX and send my
> traffic from there.
>
> About the staff rotation I’ve seen it too, and I’ve also seen an increase
> in salespeople calling, for example when an AS is registered etc. in
> addition to the normal calls..
>
> On 16 Oct 2018, at 16:54, Dovid Bender  wrote:
>
> They call me every few months. the last time they emailed me I said I
> wasn't interested because of the HE issue. I have yet to get another
> email...
>
>
> On Tue, Oct 16, 2018 at 9:29 AM, Ca By  wrote:
>
>
>
> On Tue, Oct 16, 2018 at 5:16 AM David Hubbard <
> dhubb...@dino.hostasaurus.com> wrote:
>
> Have had the same sales rep for several years now; unfortunately he has no
> ability to fix their IPv6 peering issue so we’re slowly removing circuits,
> but otherwise for a handful of 10gig DIA circuits it’s been stable.
>
>
>
>
> Yep, this.  Whenever Cogent calls, this is what i tell them. Black-holing
> HE and Google ipv6 traffic, which is what they do if i use a default route
> from them, is dead on arrival.  Shows they make bad decisions and dont put
> the customer first, or even create such an illusion.
>
>
>
>
> *From: *NANOG  on behalf of Ryan Gelobter <
> rya...@atwgpc.net>
> *Date: *Tuesday, October 16, 2018 at 6:04 AM
> *To: *NANOG 
> *Subject: *Whats going on at Cogent
>
> Anyone else seen terrible support and high turnover of sales/account
> people at Cogent the last few months? Is there something going on over
> there internally? I'm sure some people will say Cogent has always been crap
> but in the past their account reps and support were pretty good. It seems
> to have gone downhill the last 12 months really bad.
>
> Regards,
> Ryan
>
>

Re: Whats going on at Cogent

[Dovid Bender]

They call me every few months. the last time they emailed me I said I
wasn't interested because of the HE issue. I have yet to get another
email...


On Tue, Oct 16, 2018 at 9:29 AM, Ca By  wrote:

>
>
> On Tue, Oct 16, 2018 at 5:16 AM David Hubbard <
> dhubb...@dino.hostasaurus.com> wrote:
>
>> Have had the same sales rep for several years now; unfortunately he has
>> no ability to fix their IPv6 peering issue so we’re slowly removing
>> circuits, but otherwise for a handful of 10gig DIA circuits it’s been
>> stable.
>>
>>
>>
>
> Yep, this.  Whenever Cogent calls, this is what i tell them. Black-holing
> HE and Google ipv6 traffic, which is what they do if i use a default route
> from them, is dead on arrival.  Shows they make bad decisions and dont put
> the customer first, or even create such an illusion.
>
>
> *From: *NANOG  on behalf of Ryan Gelobter <
>> rya...@atwgpc.net>
>> *Date: *Tuesday, October 16, 2018 at 6:04 AM
>> *To: *NANOG 
>> *Subject: *Whats going on at Cogent
>>
>>
>>
>> Anyone else seen terrible support and high turnover of sales/account
>> people at Cogent the last few months? Is there something going on over
>> there internally? I'm sure some people will say Cogent has always been crap
>> but in the past their account reps and support were pretty good. It seems
>> to have gone downhill the last 12 months really bad.
>>
>>
>>
>> Regards,
>>
>> Ryan
>>
>

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

[Dovid Bender]

Still better than what other places charge (*cough* DR. *cough*)


On Mon, Sep 17, 2018 at 10:57 AM, Fredy Kuenzler  wrote:

> Is anyone else affected by a massive price increase for x-conns by
> Telehouse Chelsea?
>
> When we moved in a few years ago they were asking 150$, it changed to
> 200$ and now we are asked to pay 260$. That's 73% more. I don't think
> inflation is that high in the United states.
>
> I get the impression that they feel comfortable enough to abuse their
> position. When we complained they simply said 'you may consider to
> cancel the contract'.
>
> Of course they don't provide any better service, in fact, the service
> quality is commonly indirectly proportional to the price at most 'big
> names'. #rant
>
> I suggest to anyone considering to buy colocation space in NYC (or
> elsewhere) not to choose Telehouse, unlike a few years ago.
>
> --
> Fredy Kuenzler
> Init7 (Switzerland) Ltd.
>
>

Re: Avast / Privax abuse contact

[Dovid Bender]

Matt,

Rarely do we ever get a response when we file complaints for SIP traffic.
We simply use Kamilio and where have known bad UA's we just drop the
packets and ban the IP's (using Fail2Ban), it will save you a lot of grief.
It's like trying to go after every get request to phpMyAdmin.



On Wed, Aug 1, 2018 at 1:11 PM, Matt Harris  wrote:

> Anybody know anyone at or anything about Privax or Avast?  AS 198605 is
> announcing the problem networks.
>
> Getting a ton of SIP brute force attacks from their space, and emails with
> addresses/timestamps to the abuse contacts listed at RIRs/etc have not
> yieled any responses.  Attacks still coming.
>
> Thanks!
>

Re: AS205869, AS57166: Featured Hijacker of the Month, July, 2018

[Dovid Bender]

Dead for me via:
HE
NTT
COX



On Tue, Jul 24, 2018 at 3:03 AM,  wrote:

> > I'd greatly appreciate it if readers of this post would help me to to
> confirm
> > that the non-routing of the above block is both universal and complete...
> > as it is, at least, from where I am sitting... but at this point I have
> > nothing and nobody to rail against.  (Or so I thought!  But while writing
> > this post I found some new and apparently associated curiosities relating
> > to a different ASN, AS57166.  Read on!)
>
> All prefixes still visible here (Oslo, Norway), through HE. Here's your
> original table augmented with the AS paths I see on our border routers:
>
> ASN   Route AS path
> ---
> 10510 216.238.64.0/18   6939 205869 32226 10510
> 10737 207.183.96.0/20   6939 205869 7827 10737
> 10800 192.110.32.0/19   6939 205869 11717 10800
> 19529 104.143.112.0/20  6939 205869 11324 19529
> 19529 198.14.0.0/20 6939 205869 7827 19529
> 19529 198.32.208.0/20   6939 205869 7827 19529
> 19529 206.41.128.0/20   6939 205869 11324 19529
> 30237 192.73.128.0/20   6939 205869 11717 30237
> 30237 192.73.144.0/20   6939 205869 11717 30237
> 30237 192.73.160.0/20   6939 205869 11717 30237
> 30237 192.73.176.0/20   6939 205869 11717 30237
>
> Steinar Haug, Nethelp consulting, sth...@nethelp.no
>

Documenting hardware

[Dovid Bender]

I am sure this has been covered in the past but I can't seem to find it. We
need a simple solution to document connections in the date center. We don't
need anything fancy (e.g. something that will probe our hardware). We need
something where we can enter what switch ports are connected to what
servers the vlans for each port etc.

TIA.

Re: BGP in a containers

[Dovid Bender]

I know of a telco that has been doing this it helps them be able to move
around containers and not have constantly configure IP's on servers.



On Thu, Jun 14, 2018 at 3:00 PM, Brielle Bruns  wrote:

> On 6/14/2018 12:56 PM, james jones wrote:
>
>> I am working on an personal experiment and was wondering what is the best
>> option for running BGP in a docker base container. I have seen a lot blogs
>> and docs referencing Quagga. I just want to make sure I am not over
>> looking
>> any other options before I dive in. Any thoughts or suggestions?
>>
>> -James
>>
>>
> *twitches*
>
> Please don't let this be an actual thing with something as critical as BGP.
>
> --
> Brielle Bruns
> The Summit Open Source Development Group
> http://www.sosdg.org/ http://www.ahbl.org
>

Fraud Dept. Contact at T-Mobile

[Dovid Bender]

Does anyone have a contact and TMobiles Telco fraud department?

Re: USB Ethernet Adapters

[Dovid Bender]

I would stay away from the Amazon Basics 1 gig device. After a while of
using it the metal housing slides out and it falls apart.


On Mon, May 14, 2018 at 2:04 PM, Hunter Fuller  wrote:

> We have been recommending the AmazonBasics ones for this. The reason is
> because they are cheap and reliable, and everyone has Amazon Prime. I have
> not tested the VLAN functionality under Windows, but the adapter itself
> works fine under Windows, and the VLAN functionality works fine under RHEL.
>
> On Mon, May 14, 2018 at 12:57 PM TJ Trout  wrote:
>
> >
> > https://www.amazon.com/gp/product/B00BBD7NFU/ref=oh_aui_
> search_detailpage?ie=UTF8=1
> >
> > and
> >
> >
> > https://www.amazon.com/gp/product/B00X4S587K/ref=oh_aui_
> search_detailpage?ie=UTF8=1
> >
> > have both been working great for me on windows ten using an xps 13
> >
> > TJ
> >
> > On Mon, May 14, 2018 at 10:45 AM, Colton Conor 
> > wrote:
> >
> > > Our new laptops like most do not have an Ethernet adapter build in as
> > they
> > > are too slim. What USB to Ethernet adapter do you recommend and why?
> > > Ideally it would be compatible with Windows 10, and have the ability to
> > set
> > > speed, duplex and VLAN IDs if possible.
> > >
> >
> --
>
> --
> Hunter Fuller
> Network Engineer
> VBH Annex B-5
> +1 256 824 5331
>
> Office of Information Technology
> The University of Alabama in Huntsville
> Systems and Infrastructure
>

Re: Are any of you starting to get AI robocalls?

[Dovid Bender]

On Thu, Apr 5, 2018 at 11:12 AM, Brian  wrote:

> On Thu, 2018-04-05 at 07:55 -0700, Brian Kantor wrote:
>
> > So the logical conclusion is that caller ID is useless as an
> > anti-vspam measure and the situation is hopeless, so the only
> > solution is to not personally answer the phone at all -- let voice
> > mail take a message.
>
> Pretty much. We've received calls here with the CID displaying as our
> own info, and others coming up as a neighbor's number. Some even appear
> as law enforcement when they're scammers looking for donations to
> charities that don't exist. I suppose if you're going to commit one
> crime, go for broke.
>
> > This is what I have adopted on my personal landline.  With the
> > ringers disconnected.  Although I get probably a half-dozen incoming
> > calls a day, perhaps one a week will leave a message.  Most of those
> > messages are recorded announcements that started playing even before
> > the voicemail greeting finished.
>
> I've been enjoying quiet on a VoIP line with asterisk. Those who I
> know/expect/desire calls from I can route them directly to my extension,
> those others get the IVR. It works parallel to IP routing. I can go a
> few days without hearing my phone ring yet my logs are filled with
> spammers/telemarketing calls. Robo-dialers have no clue which extension
> a human may be at, and I've been doing this for over 15 years with great
> success. With a digium wildcard, this can work for POTS lines as well.
>
>
>

A simple "Thank you for calling the line of $NAME. To prove you are not a
robot press 1". That seems to weed out most of them.

Re: Are any of you starting to get AI robocalls?

[Dovid Bender]

Steve,

Any customer with a PBX has a valid reason to pass CLI that isn't theirs if 
they are passing through a call.  


Regards,

Dovid


  Original Message  
From: snasl...@medline.com
Sent: April 5, 2018 10:03
To: nanog@nanog.org
Subject: RE: Are any of you starting to get AI robocalls?

If the scam caller is spoofing the numbers then I am not quite sure how 
T-Mobile can implement the block without blocking the legit owner of the 
number.  The way to correct this as an industry is for them to inspect the 
caller-id coming in from their customer and if that customer does not own the 
number or toll free DN they are presenting, the call gets blocked.  I know they 
can do this because our SIP carrier AT will not accept outbound calls from us 
unless we present a number assigned to our account so they can bill back for 
the call.  Truthfully, the carriers do not have a real incentive to stop this 
because someone is paying to make all of those calls.  I don't believe for a 
minute that they could not stop this immediately.  A simple rule that you 
cannot make a commercial call without presenting a valid callback number would 
fix this.  There is also the FTC problem.  They do almost nothing to stop the 
violations of the Do Not Call list and you get nothing out of reporting the 
violations.  If the enforcement was anywhere near the requirements of the DCMA 
regulations, this would be reduced drastically.  First step would be to make 
the carriers liable for providing service to these scammers, then they might 
actually care.


Steven Naslund
Chicago IL





-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Ca By
Sent: Thursday, April 05, 2018 7:43 AM
To: Shawn L
Cc: nanog@nanog.org
Subject: Re: Are any of you starting to get AI robocalls?

On Wed, Apr 4, 2018 at 4:19 PM Shawn L via NANOG  wrote:

>
> Honestly, most carriers I've talked to are fed up as well, and just 
> want to find a way to make it stop.  As some one said, it's exactly 
> like BCP38
> ---  the carriers that care keep their clients from spoofing caller 
> id, etc.  The ones that don't make everyone else look bad.
>

Some carriers have a free scam call block feature

https://newsroom.t-mobile.com/news-and-blogs/scam-block.htm

Re: Are any of you starting to get AI robocalls?

[Dovid Bender]

As carriers who get these calls for our clients we hate them. Short
duration calls have the same cost as far as channels, keeping cdr's etc yet
since they are so short there isn't much to be made. This is worse then
BCP38 since with the internet there is no reason for anyone at home or a
small office to be sending out a packet that is not with their IP. When it
comes to telephony say I have a PBX, I get a call and then want to send it
out to my on call tech. I want him to see the real callers number. I need
to now "spoof" that number so my tech see's the real caller. There is a lot
more room for abuse. Now the carriers terminating the calls (the ones
getting them from the spammers) they love them. Since it's dialer/short
termination they can charge and arm and a leg.


On Wed, Apr 4, 2018 at 7:17 PM, Shawn L via NANOG  wrote:

>
> Honestly, most carriers I've talked to are fed up as well, and just want
> to find a way to make it stop.  As some one said, it's exactly like BCP38
> ---  the carriers that care keep their clients from spoofing caller id,
> etc.  The ones that don't make everyone else look bad.
>
> -Original Message-
> From: "Keith Medcalf" 
> Sent: Wednesday, April 4, 2018 7:04pm
> To: "nanog@nanog.org" 
> Subject: RE: Are any of you starting to get AI robocalls?
>
>
>
> Why would the carriers want to do anything? They are making money from
> call termination fees.
>
>
> ---
> The fact that there's a Highway to Hell but only a Stairway to Heaven says
> a lot about anticipated traffic volume.
>
> >-Original Message-
> >From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Sean
> >Pedersen
> >Sent: Wednesday, 4 April, 2018 08:45
> >To: nanog@nanog.org
> >Subject: RE: Are any of you starting to get AI robocalls?
> >
> >Yep. Add it to the list of IRS scams, fake arrest warrants, credit
> >repair, free vacations, etc. The rate of calls has increased
> >dramatically in the past year, especially with the "neighborhood
> >scam" where they spoof their CLID to a local area code and prefix +
> > through  and blast you with calls, trying to trick you into
> >thinking it's someone local and thus important or legitimate.
> >
> >I have a second phone I use for work and on-call, so that goes on DND
> >from 6PM to 6AM with a VIP list of people/numbers that can ring
> >through. No problems there, and somehow that number isn't (yet) on
> >anyone's list, so I don't get many calls.
> >
> >On my personal cell, I started to use an app called Hiya that has
> >been pretty successful. It's available for both iPhone and Android.
> >It powers a lot of the carrier-specific apps like AT Call Protect,
> >but unlike them, it doesn't suck. It's a giant database of reports
> >that rate calling numbers and classify them as fraud, scam,
> >neighborhood spoofing, etc. and you can flag them or route them right
> >to voicemail. The only time it doesn’t work is when it hasn't updated
> >its list in a little while and a few sneak through. They just
> >realized a premium version that added some features. I haven't
> >explored it yet.
> >
> >Went from about 20 calls a week to almost nothing.
> >
> >Carriers seem to be either uncapable or unwilling to address the
> >issue other than the occasional lip-service reply about "taking
> >customer's $variable seriously."
> >
> >-Original Message-
> >From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of William
> >Herrin
> >Sent: Tuesday, April 3, 2018 3:32 PM
> >To: nanog@nanog.org
> >Subject: Are any of you starting to get AI robocalls?
> >
> >Howdy.
> >
> >Have any of you started to get AI robocalls? I've had a couple of
> >calls recently where I get the connect silence of a predictive dialer
> >followed by a woman speaking with call center background noise. She
> >gives her name and asks how I'm doing. The first time it happened it
> >seemed off for reasons I can't quite articulate, so I asked: "Are you
> >a robot or a person?" She responded "yes" and then launched in to a
> >sales pitch. The next time I asked, "where can I direct your call?"
> >She responded "that's good" and launched in to her pitch.
> >
> >Regards,
> >Bill Herrin
> >
> >
> >--
> >William Herrin  her...@dirtside.com b...@herrin.us
> >Dirtside Systems . Web: 
>
>
>
>
>
>

Re: Proof of ownership; when someone demands you remove a prefix

[Dovid Bender]

Finally a use for block chain :p


On Mon, Mar 12, 2018 at 7:11 PM, Randy Bush  wrote:

> it's a real shame there is no authorative cryptographically verifyable
> attestation of address ownership.
>

Re: 60 Hudson Woes

[Dovid Bender]

What about remote hands? What I like about DR is their staff levels and
resources should there be a storm etc. they are fully staff. I rarely use
their remote hands but when I do they are golden. They also have a great
record.

On Mon, Feb 19, 2018 at 8:21 AM, James Stankiewicz <stankiew...@njedge.net>
wrote:

> Halsey Street is outstanding,,great staff and is the place to be!!
>
> On Sat, Feb 17, 2018 at 5:07 PM, Brian Knight <m...@knight-networks.com>
> wrote:
>
> > As the engineer working on that Cisco / IBM issue Erik mentioned... ;)
> >
> > I was able to get walk-up, same-day access to the building for myself a
> > few weeks ago (as a customer of DR) and didn’t get my hand slapped for
> it.
> > DR just created the access ticket with the building and that was enough.
> It
> > took about 20 minutes start to finish.
> >
> > But if a vendor tech needs access, they need a COI generated, and that
> > must be sent to the building ahead of time via DR. Otherwise they will be
> > turned away.
> >
> > The COI was the biggest blocker. A 48 hour lead time for the visit didn’t
> > seem to be enforced, not by Digital Realty anyway.
> >
> > Also, I tried to arrange for permanent building key card access while I
> > was there. But the key cards must be used at least once every 60 days,
> > otherwise they are deactivated. I decided just to arrange for access
> ahead
> > of time since I don’t visit often.
> >
> > -Brian
> >
> > > On Feb 16, 2018, at 1:50 PM, Erik Sundberg <esundb...@nitelusa.com>
> > wrote:
> > >
> > > We just had an issue where cisco was going to replace a power tray in
> > our router at 60 hudson, we are also at telx.  Cisco contracts with IBM
> for
> > this. The building is now checking that all 3rd party vendors have an
> > existing Certificate of insurance (COI). This take 48 hours to get put in
> > there system...
> > >
> > > So now we are forced to use telx smarthands if it's under 48 hours or
> > weekends
> > >
> > >
> > >
> > > -Original Message-
> > > From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Dovid Bender
> > > Sent: Friday, February 16, 2018 12:03 PM
> > > To: NANOG <nanog@nanog.org>
> > > Subject: 60 Hudson Woes
> > >
> > > We have space with Digital Realty (aka TELX) and 60 Hudson and lately
> > it's been a nightmare getting in. The real estate management company is
> > having us reconsider our options. They are giving us the option to have
> ID
> > badges for our employees but for anyone else that wants access we need to
> > request it 48 hours in advance to get approval. So if we plan on having
> an
> > unexpected outage and we need to have a have a vendor come on site (e.g.
> a
> > Dell tech) we will need to let them know in advance.
> > >
> > > What are peoples experiences with 111 8th and  165 Halsey? We really
> > like the connectivity options at 60 Hudson but at some point the hassle
> > becomes not worth it.
> >
> >
>
>
> --
> *Jim Stankiewicz*
>
> *Principal Network Architect*
> *NJEdge*
> *W:855.832.EDGE(3343)*
> *c:201.306.4409*
>

Re: 60 Hudson Woes

[Dovid Bender]

While dealing with DR is not always fun in this case it isn't their fault.
The building management is the one creating the issues. I used to have no
issues and now every time it seems like there are new rules to get in. Over
all it seems that everyone has high praise for 165 Halsey so I will start
there.


On Fri, Feb 16, 2018 at 5:17 PM, Mike Hammett <na...@ics-il.net> wrote:

> I will generally prefer the smaller operators in a market for many
> reasons, but most relevant to this situation is that they simply don't have
> the market power to be jerks. They may want to be nice, but they have to be
> nice, else people go elsewhere.
>
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
>
> Midwest Internet Exchange
>
> The Brothers WISP
>
> - Original Message -
>
> From: "Jim Grady" <jgr...@365datacenters.com>
> To: "Dovid Bender" <do...@telecurve.com>
> Cc: "NANOG" <nanog@nanog.org>
> Sent: Friday, February 16, 2018 12:38:37 PM
> Subject: Re: 60 Hudson Woes
>
> We do not have all of the carriers you can get at 60 Hudson but we do have
> many at 365 Data Centers at 65 Broadway and I can guarantee you won’t have
> the headaches from 60 Hud, and you can probably save money. Let me know if
> you have any interest and we can discuss your requirements so I can get you
> a quote.
>
> Best,
>
> Jim
>
> Sent from my iPhone
>
> > On Feb 16, 2018, at 1:04 PM, Dovid Bender <do...@telecurve.com> wrote:
> >
> > We have space with Digital Realty (aka TELX) and 60 Hudson and lately
> it's
> > been a nightmare getting in. The real estate management company is having
> > us reconsider our options. They are giving us the option to have ID
> badges
> > for our employees but for anyone else that wants access we need to
> request
> > it 48 hours in advance to get approval. So if we plan on having an
> > unexpected outage and we need to have a have a vendor come on site (e.g.
> a
> > Dell tech) we will need to let them know in advance.
> >
> > What are peoples experiences with 111 8th and 165 Halsey? We really like
> > the connectivity options at 60 Hudson but at some point the hassle
> becomes
> > not worth it.
> >
>
>

60 Hudson Woes

[Dovid Bender]

We have space with Digital Realty (aka TELX) and 60 Hudson and lately it's
been a nightmare getting in. The real estate management company is having
us reconsider our options. They are giving us the option to have ID badges
for our employees but for anyone else that wants access we need to request
it 48 hours in advance to get approval. So if we plan on having an
unexpected outage and we need to have a have a vendor come on site (e.g. a
Dell tech) we will need to let them know in advance.

What are peoples experiences with 111 8th and  165 Halsey? We really like
the connectivity options at 60 Hudson but at some point the hassle becomes
not worth it.

Re: MTU to CDN's

[Dovid Bender]

Vincent,

Thanks. That URL explained a lot.

On Tue, Jan 9, 2018 at 3:11 AM, Vincent Bernat  wrote:

>  ❦  8 janvier 2018 15:08 -0800, joel jaeggli  :
>
> >> N00b here trying to understand why certain CDN's such as Cloudfare have
> >> issues where my MTU is low. For instance if I am using pptp and the MTU
> is
> >> at 1300 it wont work. If I increase to 1478 it may or may not work.
> > PMTUD has a lot of trouble working reliability when the destination of
> > the PTB  is a stateless load-balancer.
>
> More explanations are available here:
>  https://blog.cloudflare.com/path-mtu-discovery-in-practice/
> --
> Don't comment bad code - rewrite it.
> - The Elements of Programming Style (Kernighan & Plauger)
>

MTU to CDN's

[Dovid Bender]

Hi,

N00b here trying to understand why certain CDN's such as Cloudfare have
issues where my MTU is low. For instance if I am using pptp and the MTU is
at 1300 it wont work. If I increase to 1478 it may or may not work.

TIA.

Re: Attacks from poneytelecom.eu

[Dovid Bender]

I may have to take back what I said. Yes the attacks stopped from what IP
but they magically started again from another IP of theirs in a different.
Range. seems like the attacker picked up where they left off just from a
new UP. Almost as if they told the attacker they got complaints and they
would need to just simply switch their IP to keep them as a customer..


On Thu, Jan 4, 2018 at 9:42 AM, Dovid Bender <do...@telecurve.com> wrote:

> In their defense I was pleasantly surprised that I got a response back
> from them telling me the account was banned. Though it makes me wonder if
> this is just them trying to save face. I have spoken with the guys that run
> DO's network and they have an extensive amount of automation to weed out
> spammers, attackers etc. It makes you wonder why for years that are known
> in the spammer community as a safe heaven.
>
> On Thu, Jan 4, 2018 at 9:33 AM, William Herrin <b...@herrin.us> wrote:
>
>> On Wed, Jan 3, 2018 at 10:57 PM, Dan Hollis <goe...@sasami.anime.net>
>> wrote:
>>
>>> On Wed, 3 Jan 2018, Dovid Bender wrote:
>>>
>>>> On Wed, Jan 3, 2018 at 2:47 AM, Mickael Marchand <
>>>> mmarch...@corp.free.fr>
>>>> wrote:
>>>>
>>>>> Hi Dovid,
>>>>>
>>>>> Just fill in our abuse form at https://abuse. <https://abuse.scaleway>
>>>>> online.net
>>>>>
>>>>
>>> I have no idea why anyone thinks it is acceptable to require victims to
>>> fill out online web forms.
>>
>>
>> Because the number of people who successfully provide actionable
>> information without being prompted is vanishingly small and the number of
>> people who fire off automated complaints to the best guess abuse address
>> (also without actionable information) is disappointingly large?
>>
>> Why anyone thinks it's acceptable for the form submission to vanish in to
>> the faceless support queue is more of a quandary. The form submission
>> should provide a case number, the individual to whom it is assigned, direct
>> contact information for that individual and a promise that your report will
>> receive a response.
>>
>> Regards,
>> Bill Herrin
>>
>>
>> --
>> William Herrin  her...@dirtside.com  b...@herrin.us
>> Dirtside Systems . Web: <http://www.dirtside.com/>
>>
>
>

Re: IPv4 smaller than /24 leasing?

[Dovid Bender]

I can tell you that when we started (and there were IP's still available)
we first leased from another company to get our feet when and run tests
before we requested our own resources.

On Thu, Jan 4, 2018 at 6:21 PM, William Herrin  wrote:

> On Thu, Jan 4, 2018 at 6:06 PM, Mike Hammett  wrote:
>
> > There are hundreds of ISPs with under 500 customers. More start up every
> > week. No need to marginalize them.
> >
>
> Hi Mike,
>
> No disrespect, but anyone who can't afford to spend $5000 on resources
> critical to their activity is not in the Internet business or any other
> kind of business and should probably stop lying to themselves about that.
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin  her...@dirtside.com  b...@herrin.us
> Dirtside Systems . Web: 
>

Re: Attacks from poneytelecom.eu

[Dovid Bender]

In their defense I was pleasantly surprised that I got a response back from
them telling me the account was banned. Though it makes me wonder if this
is just them trying to save face. I have spoken with the guys that run DO's
network and they have an extensive amount of automation to weed out
spammers, attackers etc. It makes you wonder why for years that are known
in the spammer community as a safe heaven.

On Thu, Jan 4, 2018 at 9:33 AM, William Herrin <b...@herrin.us> wrote:

> On Wed, Jan 3, 2018 at 10:57 PM, Dan Hollis <goe...@sasami.anime.net>
> wrote:
>
>> On Wed, 3 Jan 2018, Dovid Bender wrote:
>>
>>> On Wed, Jan 3, 2018 at 2:47 AM, Mickael Marchand <mmarch...@corp.free.fr
>>> >
>>> wrote:
>>>
>>>> Hi Dovid,
>>>>
>>>> Just fill in our abuse form at https://abuse. <https://abuse.scaleway>
>>>> online.net
>>>>
>>>
>> I have no idea why anyone thinks it is acceptable to require victims to
>> fill out online web forms.
>
>
> Because the number of people who successfully provide actionable
> information without being prompted is vanishingly small and the number of
> people who fire off automated complaints to the best guess abuse address
> (also without actionable information) is disappointingly large?
>
> Why anyone thinks it's acceptable for the form submission to vanish in to
> the faceless support queue is more of a quandary. The form submission
> should provide a case number, the individual to whom it is assigned, direct
> contact information for that individual and a promise that your report will
> receive a response.
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin  her...@dirtside.com  b...@herrin.us
> Dirtside Systems . Web: <http://www.dirtside.com/>
>

Re: Attacks from poneytelecom.eu

[Dovid Bender]

Mcikael,

1) As others have mentioned your AS seemingly has a history of tolerating
abuse. I know some of the other VPS players such as DO have automated
scripts that look for attacks and lock them out. I see you peer with them
perhaps they can share some scripts ;)
2) I went to the abuse URL you have posted and it just lands at your main
page.

The offending IP was 195.154.182.242. I checked two different boxes (one
our own range and another a hosted box elsewhere) and both have entries in
the last 3 days from that IP. Scans have been going on for at least the
last 48+ hours.





On Wed, Jan 3, 2018 at 2:47 AM, Mickael Marchand <mmarch...@corp.free.fr>
wrote:

> Hi Dovid,
>
> Just fill in our abuse form at https://abuse. <https://abuse.scaleway>
> online.net
>
> I know people feel these are not processed but they actually are (and
> human reviewed)
> we are improving our automated tracking of bad guys
> more reports come in, easier it is in the end.
>
> note that most IPs you report are rented per minute and it’s usually not
> the same account (but often the same IP as they are reused quickly I agree),
> we are working on killing these accounts as fast as we can
>
> we have a long awaited overall of our abuse system coming in the next
> months and additional global scale network security in the pipe (automated
> SIP scan detection and blocking is among them for example)
>
> regards
> Mik
>
>
> Le 3 janv. 2018 à 04:11, Ahad Aboss <a...@swiftelnetworks.com> a écrit :
>
> Have you emailed their abuse or NOC teams with the attack logs from their
> IPs?
>
> Sometimes ISP servers or their customer CPEs are compromised without their
> knowledge.
>
> On Wed, 3 Jan 2018 at 1:56 pm, Dovid Bender <do...@telecurve.com> wrote:
>
> Hi All,
>
> Lately we have seen a lot of attacks from IPs where the PTR record ends in
> poneytelecom.eu to PBX systems. A quick search on twitter (
> https://twitter.com/hashtag/poneytelecom) shows multiple people
> complaining
> that they reported the IP's yet nothing happens. Has anyone had the
> pleasure of dealing with them and have you gotten anywhere? I wonder if the
> only option is public shaming.
>
> I would rather not ban their AS as it may hurt legit traffic but I am out
> of ideas at this point
>
> TIA.
>
> Dovid
>
>
> --
> Mickael Marchand,
> VP Network Scaleway - Online.net
> Looking for an amazing job? Join us NOW ! https://careers.scaleway.com/
>
>
>
>

Attacks from poneytelecom.eu

[Dovid Bender]

Hi All,

Lately we have seen a lot of attacks from IPs where the PTR record ends in
poneytelecom.eu to PBX systems. A quick search on twitter (
https://twitter.com/hashtag/poneytelecom) shows multiple people complaining
that they reported the IP's yet nothing happens. Has anyone had the
pleasure of dealing with them and have you gotten anywhere? I wonder if the
only option is public shaming.

I would rather not ban their AS as it may hurt legit traffic but I am out
of ideas at this point

TIA.

Dovid

Re: Contacting AS6589 - "Beneficial Technologies"

[Dovid Bender]

Public shaking seems to work. They are no longer advertising those
prefixes.

On Fri, Dec 1, 2017 at 10:30 AM, Nathan Brookfield <
nathan.brookfi...@simtronic.com.au> wrote:

> The remainder of the advertisements being more /16’s from China Seems
> very very bogus.
>
> Nathan Brookfield
> Chief Executive Officer
>
> Simtronic Technologies Pty Ltd
> http://www.simtronic.com.au
>
> On 2 Dec 2017, at 02:27, Carlos M. Martinez > wrote:
>
> Hello all,
>
> I’m trying to reach anyone at AS 6589, “Beneficial Technologies”. They are
> announcing large chunk of LACNIC unallocated space, as can be seen here:
> https://bgp.he.net/AS6589
>
> Although I usually give people the benefit of doubt, in this case we are
> talking about 5 /16 prefixes. Talk about fat fingers.
>
> Private email is ok.
>
> Thanks
>
> Carlos
> LACNIC CTO
>