Re: UK, NL, & Asia LTE Providers for Opengear Console Servers

[Louis Kowolowski]

I’ve used them in both cellular and non-cellular capacities and been pleased 
with them. AFAIK they can be setup as an IPSec terminator for clients and block 
other traffic, which lowers the attack surface a bit. I’ve also seen people try 
to use “all the features”, set them up as DNS/DHCP/etc and attach them to 
multiple networks because they are “a linux box”. Its not great. Treat them as 
a console server and you’ll be happy. Treat them as a general purpose linux 
“server” and you’ll be disappointed at the lack of flexibility in doing things.

I just used swisscom in Zurich. I would expect Orange would probably cover both 
UK and NL, but don’t know for sure. Haven’t had to do anything in Asia recently.



> On Jul 31, 2019, at 9:53 PM, JASON BOTHE via NANOG  wrote:
> 
> Are the Opengear boxes good gear? We currently have some boxes with a high 
> failure rate and I’ve been on the hunt for something we can leverage globally 
> that support LTE. 
> 
> J~ 
> 
> On Jul 31, 2019, at 21:19, Mehmet Akcin  > wrote:
> 
>> Google Fi
>> 
>> On Wed, Jul 31, 2019 at 18:35 Ryan Gelobter > > wrote:
>> Anyone have recommendations for providers who I can use for LTE on Opengear 
>> console servers in the UK, Netherlands, and Singapore? 1 provider for all 3 
>> countries would be great but I'll take what I can get. Oddly when talking to 
>> Opengear they don't really have any great advice. We use Verizon SIM cards 
>> in the US with static IPs.
>> 
>> Thanks,
>> Ryan
>> -- 
>> Mehmet
>> +1-424-298-1903

--
Louis Kowolowskilou...@cryptomonkeys.org 

Cryptomonkeys:   http://www.cryptomonkeys.com/ 


Making life more interesting for people since 1977

Re: UK, NL, & Asia LTE Providers for Opengear Console Servers

[JASON BOTHE via NANOG]

Are the Opengear boxes good gear? We currently have some boxes with a high 
failure rate and I’ve been on the hunt for something we can leverage globally 
that support LTE. 

J~ 

> On Jul 31, 2019, at 21:19, Mehmet Akcin  wrote:
> 
> Google Fi
> 
>> On Wed, Jul 31, 2019 at 18:35 Ryan Gelobter  wrote:
>> Anyone have recommendations for providers who I can use for LTE on Opengear 
>> console servers in the UK, Netherlands, and Singapore? 1 provider for all 3 
>> countries would be great but I'll take what I can get. Oddly when talking to 
>> Opengear they don't really have any great advice. We use Verizon SIM cards 
>> in the US with static IPs.
>> 
>> Thanks,
>> Ryan
> -- 
> Mehmet
> +1-424-298-1903

Re: UK, NL, & Asia LTE Providers for Opengear Console Servers

[Mehmet Akcin]

Google Fi

On Wed, Jul 31, 2019 at 18:35 Ryan Gelobter  wrote:

> Anyone have recommendations for providers who I can use for LTE on
> Opengear console servers in the UK, Netherlands, and Singapore? 1 provider
> for all 3 countries would be great but I'll take what I can get. Oddly when
> talking to Opengear they don't really have any great advice. We use Verizon
> SIM cards in the US with static IPs.
>
> Thanks,
> Ryan
>
-- 
Mehmet
+1-424-298-1903

UK, NL, & Asia LTE Providers for Opengear Console Servers

[Ryan Gelobter]

Anyone have recommendations for providers who I can use for LTE on Opengear
console servers in the UK, Netherlands, and Singapore? 1 provider for all 3
countries would be great but I'll take what I can get. Oddly when talking
to Opengear they don't really have any great advice. We use Verizon SIM
cards in the US with static IPs.

Thanks,
Ryan

Re: Estimated LTE Data Utilization in Failover Scenario

[Sabri Berisha]

- On Jul 31, 2019, at 9:54 AM, nanog nanog@nanog.org wrote:

Hi,

> From the testing I have done with VZ 4G
> I get 10mbs down and 2/3 up with a -65 RSSI. It’s still better to have LTE
> for a backup then not to have it.

You will have to keep in mind that if there is a generic service outage in your 
area, you will not be the only one going LTE/4G for backup purposes. That means 
you will kind of have to lower your expectations in a real world scenario...

> Again like I said a backup of any kind even if not sufficient in bandwidth
> is better than nothing.

That I totally agree with.

Thanks,

Sabri

Re: really amazon?

[Rich Kulawiec]

On Thu, Aug 01, 2019 at 12:54:07AM +0300, Scott Christopher wrote:
> Rich Kulawiec wrote: 
> 
> > On Wed, Jul 31, 2019 at 11:13:48PM +0300, Scott Christopher wrote:
> > > Because it will get spammed if publicly listed in WHOIS.
> > 
> > Yes.  It will.  Are you telling us that Amazon, with its enormous financial
> > and personnel resources, doesn't have ANYBODY on staff who knows how to
> > properly manage an abuse@ address -- part of which includes dealing
> > with that exact problem?
> 
> They do, but it's just time-consuming and inefficient. You can't spam-filter
> the content of abuse@ obviously.

Actually, yes, you can -- but probably not in the way you're thinking, because
if you do it *that* way you will break [some of the] required functionality.

> But in addition to spam, random (read: non-technical) people will send
> complaints outside of the usual purview of spam, network abuse, DMCA,
> etc. They find some FAQ on the web telling them to determine the PoC on
> whois.domaintools.com and then they start firing crap.

This is not my first day on the job.  I'm aware of what shows up at
role addresses.  However, handling the problems you enumerate here is a
straightforward (albeit occasionally tedious) matter that any operations
engineer above entry-level should be able to handle.  Doubly so because
people like me have done them the favor of writing about it (here and
elsewhere), so they can use our experience without needing to repeat
our numerous mistakes.

> I prefer openness and transparency and the general spirit of WHOIS but, in 
> practice,
> you really do need the limit the PoC information to a trusted group of 
> insiders.

First, there's no such thing as a trusted group of insiders.

Second, even if such a group existed, limiting PoC information to
them is impossible.  Think about it.

Third, besides WHOIS PoC, RFC 2142 (and decades of best practices)
specify abuse@, postmaster@, etc.  My expectation is that anyone
equipped with baseline competence will be fully prepared to handle
traffic to those addresses (as applicable) effectively at whatever
scale their operation requires.

---rsk

Re: User Unknown (WAS: really amazon?)

[Mark Andrews]

Actually if ARIN doesn’t pull the resources, after notification and a grace 
period to
get them fixed, then what is the point in writing policy requiring that they be 
up to
date and working?  There needs to be checks and balances for systems to work.  
The only
thing is what should the grace period be?

> On 1 Aug 2019, at 7:31 am, Scott Christopher  wrote:
> 
> Sandra Murphy wrote: 
> 
>> Scott, you might want to read "Policy Development Process (PDP)” 
>> https://www.arin.net/participate/policy/pdp/ in order to discover just 
>> exactly what John means by “If the community developed a policy”. 
>> 
>> You might also want to join the Public Policy Mailing List, 
>> arin-p...@arin.net, to discuss.  Scintillating discourse, I assure you.
> 
> Yes - I am aware of how ARIN functions, its mandate, its governance, etc.
> 
> What I have been saying is that, if ARIN did something so brazen as to revoke 
> Amazon's resources because of some bounced PoC emails, the impact would be 
> *dramatic* and likely lead to the end of ARIN. Just think about this for a 
> minute. :) Obviously this will not happen because ARIN is so righteously 
> competent. :)
> 
> I wasn't criticizing ARIN (or anybody) I was just answering a hypothetical.
> 
> -- 
> S.C.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

Re: User Unknown (WAS: really amazon?)

[Joe Provo]

On Tue, Jul 30, 2019 at 04:02:58PM +0300, T??ma Gavrichenkov wrote:
> On Tue, Jul 30, 2019 at 1:20 PM Christoffer Hansen
>  wrote:
> > Imagine ARIN did a take from RIPE NCC [Policy Proposal Idea?] and a
> > policy came into effect of validating ALL 'OrgAbuseEmail' objects listed
> > in the ARIN database.
> 
> Just to be precise, such a policy (2019-04) is still in a discussion
> phase in RIPE and has already seen significant resistance.
> 
> You can, however, point fingers at APNIC instead, where pretty much
> the same policy proposal from the same authors (prop-125) was already
> implemented in apnic-127-v006 "Internet Number Resource Policies".
> 
> I think they will be planning to reach out to ARIN with the same text
> right after the RIPE process ends this way or another.
 
Uh, ARIN-2019-5 has been in the ARIN PDP since March of this year.
See https://www.arin.net/participate/policy/drafts/2019_5/
Most recent related PPML thread: 
https://lists.arin.net/pipermail/arin-ppml/2019-July/067241.html

Cheers,

Joe

-- 
Posted from my personal account - see X-Disclaimer header.
Joe Provo / Gweep / Earthling 

Re: really amazon?

[Scott Christopher]

Rich Kulawiec wrote: 

> On Wed, Jul 31, 2019 at 11:13:48PM +0300, Scott Christopher wrote:
> > Because it will get spammed if publicly listed in WHOIS.
> 
> Yes.  It will.  Are you telling us that Amazon, with its enormous financial
> and personnel resources, doesn't have ANYBODY on staff who knows how to
> properly manage an abuse@ address -- part of which includes dealing
> with that exact problem?

They do, but it's just time-consuming and inefficient. You can't spam-filter 
the content of abuse@ obviously.

But in addition to spam, random (read: non-technical) people will send 
complaints outside of the usual purview of spam, network abuse, DMCA, etc. They 
find some FAQ on the web telling them to determine the PoC on 
whois.domaintools.com and then they start firing crap.

I prefer openness and transparency and the general spirit of WHOIS but, in 
practice, you really do need the limit the PoC information to a trusted group 
of insiders.

-- 
S.C.

Re: User Unknown (WAS: really amazon?)

[Scott Christopher]

Sandra Murphy wrote: 

> Scott, you might want to read "Policy Development Process (PDP)” 
> https://www.arin.net/participate/policy/pdp/ in order to discover just 
> exactly what John means by “If the community developed a policy”. 
> 
> You might also want to join the Public Policy Mailing List, 
> arin-p...@arin.net, to discuss.  Scintillating discourse, I assure you.

Yes - I am aware of how ARIN functions, its mandate, its governance, etc.

What I have been saying is that, if ARIN did something so brazen as to revoke 
Amazon's resources because of some bounced PoC emails, the impact would be 
*dramatic* and likely lead to the end of ARIN. Just think about this for a 
minute. :) Obviously this will not happen because ARIN is so righteously 
competent. :)

I wasn't criticizing ARIN (or anybody) I was just answering a hypothetical.

-- 
S.C.

Re: User Unknown (WAS: really amazon?)

[Sandra Murphy]

Scott, you might want to read "Policy Development Process (PDP)” 
https://www.arin.net/participate/policy/pdp/ in order to discover just exactly 
what John means by “If the community developed a policy”. 

You might also want to join the Public Policy Mailing List, arin-p...@arin.net, 
to discuss.  Scintillating discourse, I assure you.

—Sandy




> On Jul 31, 2019, at 10:17 AM, Scott Christopher  wrote:
> 
> John Curran wrote: 
> 
>> Scott - 
>> 
>> Alas, you have a fundamental misunderstanding about the nature of ARIN…  we 
>> don’t do anything other than implement policies that this community wants.  
>> If the community developed a policy to require Abuse POC’s validation, and 
>> said policy made clear that failure to do so was to result in revocation, 
>> then ARIN would indeed implement the policy (and that includes revocation 
>> for those who ignored the policy.) 
> 
> Hello John - you are absolutely right. Since the community has shown 
> overwhelming disapproval of Amazon's invalid abuse POC, please go ahead and 
> revoke Amazon's resources.
> 
> Maybe do this late Friday afternoon for the courtesy toward Amazon's support 
> staff ?
> 
> And since this will certainly be historic, please post an announcement to 
> nanog-list ?
> 
> Thanks, and Good luck !
> 
> S.C.

Re: really amazon?

[Landon Stewart]

On Jul 31, 2019, at 1:13 PM, Scott Christopher  wrote:
> 
> Valdis Klētnieks wrote:
> 
>> On Wed, 31 Jul 2019 16:36:08 -, Richard Williams via NANOG said:
>> 
>>> To contact AWS SES about spam or abuse the correct email address is 
>>> ab...@amazonaws.com
>> 
>> You know that, and I know that, but why doesn't the person at AWS whose job 
>> it
>> is to keep the ARIN info correct and up to date know that?
> 
> Because it will get spammed if publicly listed in WHOIS.

Not an excuse.  I’m saying this on behalf of ALL the other ASNs that keep their 
POCs up to date.


signature.asc
Description: Message signed with OpenPGP

Re: really amazon?

[Rich Kulawiec]

On Wed, Jul 31, 2019 at 11:13:48PM +0300, Scott Christopher wrote:
> Because it will get spammed if publicly listed in WHOIS.

Yes.  It will.  Are you telling us that Amazon, with its enormous financial
and personnel resources, doesn't have ANYBODY on staff who knows how to
properly manage an abuse@ address -- part of which includes dealing
with that exact problem?

---rsk

Re: really amazon?

[Stephen Satchell]

On 7/31/19 1:28 PM, Brian J. Murrell wrote:
> On Wed, 2019-07-31 at 23:13 +0300, Scott Christopher wrote:
>>
>> Because it will get spammed if publicly listed in WHOIS.
> 
> I will take that at *least* as ironic as you meant it.

I don't know about your network, but I have five role mail accounts, and
all five get spam, even with spam filters enabled.  Oh, forgot about
abuse@, which has no filter but LOTS of spam.  What's fun is to let it
sit a couple of days, then sort by subject.  Delete the "conversations".

That gets down to the zero or one piece of ham.  But then again, I've
locked down my network so abuse doesn't get out, even when someone
manages to get by the MAC filters on the wireless router.

Re: really amazon?

[Stephen Satchell]

On 7/31/19 12:04 PM, Valdis Klētnieks wrote:
> On Wed, 31 Jul 2019 16:36:08 -, Richard Williams via NANOG said:
> 
>>  To contact AWS SES about spam or abuse the correct email address is 
>> ab...@amazonaws.com
> 
> You know that, and I know that, but why doesn't the person at AWS whose job it
> is to keep the ARIN info correct and up to date know that?

C'mon, you already know the answer to this:  there is no such person.
Someone gets a mail once a year and MIGHT, JUST MIGHT, pass it on to
someone who knows what to do.

Re: really amazon?

[Brian J. Murrell]

On Wed, 2019-07-31 at 23:13 +0300, Scott Christopher wrote:
> 
> Because it will get spammed if publicly listed in WHOIS.

I will take that at *least* as ironic as you meant it.

b.



signature.asc
Description: This is a digitally signed message part

Re: really amazon?

[Denys Fedoryshchenko]

On 2019-07-31 23:13, Scott Christopher wrote:

Valdis Klētnieks wrote:


On Wed, 31 Jul 2019 16:36:08 -, Richard Williams via NANOG said:

>  To contact AWS SES about spam or abuse the correct email address is 
ab...@amazonaws.com

You know that, and I know that, but why doesn't the person at AWS 
whose job it

is to keep the ARIN info correct and up to date know that?


Because it will get spammed if publicly listed in WHOIS.


They can send autoreply with correct address (even as picture, but yes, 
From: can be spoofed, so might be bad idea), make error message with 
link to captcha, custom error

in reject (e.g. web url to submit report), and etc.
So many ways to be more helpful in such critical matters.

But at least not "User not found".

Re: really amazon?

[Scott Christopher]

Valdis Klētnieks wrote: 

> On Wed, 31 Jul 2019 16:36:08 -, Richard Williams via NANOG said:
> 
> >  To contact AWS SES about spam or abuse the correct email address is 
> > ab...@amazonaws.com
> 
> You know that, and I know that, but why doesn't the person at AWS whose job it
> is to keep the ARIN info correct and up to date know that?

Because it will get spammed if publicly listed in WHOIS.

-- 
S.C.

[NANOG-announce] Reminder: NANOG 77 call for presentations is open

[Benson Schliesser]

NANOG Community -

As a reminder, the NANOG Program Committee (PC) is still accepting
proposals for talks, tutorials, tracks & panels at the upcoming NANOG 77 in
Austin, Texas, October 28-30, 2019.

Below is a summary of key details and dates from the Call For Presentations
on the NANOG website, which can be found at
https://nanog.org/meetings/nanog-77/.

Presentations may cover current technologies, soon-to-be deployed
technologies, and industry innovation. Vendors are welcome to submit talks
which cover relevant technologies and capabilities, but presentations
should not be promotional, or discuss proprietary solutions.


The primary speaker, moderator, or author should submit a presentation
proposal and abstract via the PC Tool at: https://pc.nanog.org

   -

   Select “Propose Talk” from the “Talks” menu
   -

   Select NANOG 77 from the Meeting menu
   -

   Select the appropriate *Session* the talk will be presented in
   -

  General Session (30-45 minutes)
  -

  Tutorial (90-120 minutes)
  -

  Track (90-120 minutes)


Key dates for NANOG 77:

Date

Event/Deadline

Aug. 19, 2019

CFP Deadline

Sep. 23, 2019

CFP Topic List & NANOG Meeting Highlights Page posted

Sep. 30, 2019

NANOG 77 Agenda Posted

Oct. 21, 2019

Speaker FINAL presentations DUE (NO CHANGES accepted after this date)

Oct. 27, 2019

Lightning Talk Submissions Open, Onsite Registration Begins


We look forward to seeing you in October in Austin, Texas!

Sincerely,

Benson Schliesser

On behalf of the NANOG PC
___
NANOG-announce mailing list
NANOG-announce@nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-announce

Reminder: NANOG 77 call for presentations is open

[Benson Schliesser]

NANOG Community -

As a reminder, the NANOG Program Committee (PC) is still accepting
proposals for talks, tutorials, tracks & panels at the upcoming NANOG 77 in
Austin, Texas, October 28-30, 2019.

Below is a summary of key details and dates from the Call For Presentations
on the NANOG website, which can be found at
https://nanog.org/meetings/nanog-77/.

Presentations may cover current technologies, soon-to-be deployed
technologies, and industry innovation. Vendors are welcome to submit talks
which cover relevant technologies and capabilities, but presentations
should not be promotional, or discuss proprietary solutions.


The primary speaker, moderator, or author should submit a presentation
proposal and abstract via the PC Tool at: https://pc.nanog.org

   -

   Select “Propose Talk” from the “Talks” menu
   -

   Select NANOG 77 from the Meeting menu
   -

   Select the appropriate *Session* the talk will be presented in
   -

  General Session (30-45 minutes)
  -

  Tutorial (90-120 minutes)
  -

  Track (90-120 minutes)


Key dates for NANOG 77:

Date

Event/Deadline

Aug. 19, 2019

CFP Deadline

Sep. 23, 2019

CFP Topic List & NANOG Meeting Highlights Page posted

Sep. 30, 2019

NANOG 77 Agenda Posted

Oct. 21, 2019

Speaker FINAL presentations DUE (NO CHANGES accepted after this date)

Oct. 27, 2019

Lightning Talk Submissions Open, Onsite Registration Begins


We look forward to seeing you in October in Austin, Texas!

Sincerely,

Benson Schliesser

On behalf of the NANOG PC

Re: really amazon?

[Valdis Klētnieks]

On Wed, 31 Jul 2019 16:36:08 -, Richard Williams via NANOG said:

>  To contact AWS SES about spam or abuse the correct email address is 
> ab...@amazonaws.com

You know that, and I know that, but why doesn't the person at AWS whose job it
is to keep the ARIN info correct and up to date know that?



pgpQore3kQHKu.pgp
Description: PGP signature

RE: Estimated LTE Data Utilization in Failover Scenario

[Paul Amaral via NANOG]

In my experience with LTE is that it’s never enough. We have bank branches
with 20Mbs metro lines and on rare occasion when that circuit drops 4G LTE
will provide you with 10mbs at best also note that latency is much higher
which can mess with ipsec/VOIP etc. I don’t think you can pick how much
bandwidth you will get with 4G LTE. From the testing I have done with VZ 4G
I get 10mbs down and 2/3 up with a -65 RSSI. It’s still better to have LTE
for a backup then not to have it. 

I have used cradlepoint and now switched to cisco ISR . I find the
crandlepoint to be not as reliable as the cisco ISR. The cradlepoint will
get extremely hot, go down for no reason and has poor signal compared to the
ISR  with LTE.  I would stay away from the cradlepoint and find a Cisco
LTE solution. 

Again like I said a backup of any kind even if not sufficient in bandwidth
is better than nothing.



Paul

From: NANOG  On Behalf Of Shaun Dombrosky
Sent: Tuesday, July 30, 2019 12:06 PM
To: 'nanog@nanog.org' 
Subject: Estimated LTE Data Utilization in Failover Scenario

Good Morning,

First time NANOG poster, apologies if I breach etiquette.

Does anyone have any first-hand data on how much data a small-medium
business (SMB) can expect to consume in a failover scenario over a 4G/LTE
connection?  Retail, under 50 head count, using PoS, maybe cloud accounting
software, general internet activity, 8 hour time period.  Wonder if anyone
is using a Cradlepoint or SD-WAN solution that could pull a few quick
numbers from a dashboard for me.  I haven’t had much luck in my searches.

Appreciate any info anyone can provide.

Thanks,

Shaun Dombrosky
Data Network Engineer



E: mailto:sdombro...@blackfoot.com
http://www.blackfoot.com/ 

Stay connected with Blackfoot:

https://www.facebook.com/GoBlackfoot/?utm_source=Outlook_medium=Sig_
name=2017EmpSig_content=Social 
https://www.linkedin.com/company/blackfoot-telecommunications-group/?utm_sou
rce=Outlook_medium=Sig_name=2017EmpSig_content=Social  http://ww
w.twitter.com/GoBlackfoot/?utm_source=Outlook_medium=Sig_name=2017Em
pSig_content=Social  https://www.youtube.com/BlackfootTelecom?utm_source
=Outlook_medium=Sig_name=2017EmpSig_content=Social


This e-mail and any files transmitted with it are confidential and are
intended solely for the use of the individual or entity to which they are
addressed.  If you are not the intended recipient or the person responsible
for delivering the e-mail to the intended recipient, be advised that you
have received this e-mail in error and that any use, dissemination,
forwarding, printing, or copying of this e-mail is strictly prohibited. If
you have received this e-mail in error, please immediately reply to the
sender by email notifying them of the error and delete the original and
reply copies. Thank you.

Re: really amazon?

[Richard Williams via NANOG]

 To contact AWS SES about spam or abuse the correct email address is 
ab...@amazonaws.com
On Wednesday, July 31, 2019, 9:53:59 AM EDT, Rich Kulawiec  
wrote:  
 
 
Yes, this is egregious, but on the other hand even when the abuse
reporting mechanisms are working my experience has been that they
emit no response (other than -- maybe -- boilerplate) and take no
action, so it's not terribly surprising.

---rsk
  

The future of transport in the metro area

[Etienne-Victor Depasquale]

Hello,

I'm new to this mailing list. I hope I've understood the scope correctly!

I've posted this question to ResearchGate but I haven't had any response.
I'm hoping for some guidance from here.

The question is:

"I'm trying to identify trends in adoption of transport technology in the
metro-area. If legacy is SDH/SONET and its successor in circuit transport
is OTN, what are network providers implementing and planning to implement
as transport technology in the metro area? For example, are packet
transport technologies being considered as a replacement? As a
complementary technology? By packet transport technologies, I am thinking
of PBB-TE and MPLS-TP but ultimately, the problem regards how network
providers are balancing circuit-transport and packet-transport technologies
in current and planned deployments."


-- 
Ing. Etienne-Victor Depasquale
Assistant Lecturer
Department of Communications & Computer Engineering
Faculty of Information & Communication Technology
University of Malta
Web. https://www.um.edu.mt/profile/etiennedepasquale

Re: email delays from Google

[Christopher Morrow]

Trey, the bees behind the hive say:
  "Please open an issue in this system:
   https://issuetracker.google.com/issues/new?component=191885;

>From what I can tell there are other folk with similar problems so
some triangulation on 'what is actually wrong here?' is in order.

On Wed, Jul 31, 2019 at 10:28 AM Trey Nolen  wrote:
>
> We have been experiencing delays / failures receiving email from domains
> hosted by Google and *only* domains hosted by Google.
>
> This is happening to customers for whom we host the authoritative DNS
> servers.   For some reason, Google is not able to look up the MX and/or
> A record *sometimes* from our servers.
>
> Customers are getting an error like this:
> --BEGIN
> DNS Error: 49391460 DNS type ‘mx’ lookup of 
> responded with code NOERROR 49391460 DNS type ‘’ lookup of
> mail.internetpro.net . responded with code
> SERVFAIL 49391460 DNS type ‘a’ lookup of mail.internetpro.net
> . responded with code SERVFAIL
>
> --END
>
> In the above case, Google is saying they can't find our mail server.
> There is no  record, so that part is normal.
>
> However, we have other customers who are hosting their own mail servers
> or are using relay services such as Trend Micro who are also having a
> similar issue.  The only thing these customers have in common is our DNS
> and the fact that Google is trying to send email to them.
>
> I can query Google's public servers at 8.8.8.8 and 8.8.4.4 and they
> always give the correct answers, but it seems that internally, Google is
> unable to make these lookups.   Reaching out to their support agents
> online, the agents confirm that the correct entries are in place and
> that *some* of Google's servers can't do the resolution resulting in
> sporadic email delivery.  They suggest that we reach out to the DNS
> provider to find out why (Grrr)
>
> We've also had reports from customers that the failures seem to be
> location oriented with western US emails being held up and eastern US
> emails coming through.  I can't independently confirm that, though.
>
> A full 100% of the email delivery issues have been Google hosted
> domains.   It seems that every other ISP can do the lookups just fine,
> but getting in touch with someone at Google who can troubleshoot this is
> impossible for a small ISP like us.
>
> If anyone can point me to somone at Google who could help me out, I'd be
> very thankful.
>
>
> Trey Nolen
>
>

Re: Estimated LTE Data Utilization in Failover Scenario

[Shawn Ritchie]

> On Jul 31, 2019, at 11:03 AM, Blake Hudson  wrote:
> 
> Matt Harris wrote on 7/31/2019 9:46 AM:
>> On Wed, Jul 31, 2019 at 9:21 AM Shaun Dombrosky > > wrote:
>> Good Morning,
>> 
>> First time NANOG poster, apologies if I breach etiquette.
>> 
>> Does anyone have any first-hand data on how much data a small-medium 
>> business (SMB) can expect to consume in a failover scenario over a 4G/LTE 
>> connection?  Retail, under 50 head count, using PoS, maybe cloud accounting 
>> software, general internet activity, 8 hour time period.  Wonder if anyone 
>> is using a Cradlepoint or SD-WAN solution that could pull a few quick 
>> numbers from a dashboard for me.  I haven’t had much luck in my searches.
>> 
>> Appreciate any info anyone can provide.
>> 
>> Thanks,
>> 
>> 
>> Hey Shaun,
>> I'd recommend pulling that data from the device normally facing their 
>> internet connection. Does it support netflow or even just basic snmp 
>> statistics that you could graph? Ostensibly the traffic level would be the 
>> same regardless of whether using an LTE backup connection or the primary 
>> internet connection unless you somehow prohibited certain traffic when on 
>> LTE. Ultimately though, your best bet is going to be to get real stats over 
>> the course of a couple of weeks and then you'll understand better the 
>> traffic patterns based on time of day, day of the week, etc, as well, as 
>> this is likely relevant. 
>> 
>> Good luck! 
>> 
> 100% agree with Matt. Something also to keep in mind is the SMB's peak data 
> rates. The primary (I assume ethernet) uplink may have a sub 10ms latency and 
> 100Mbps or greater data rate while the LTE connection is probably several 
> times slower in terms of bandwidth and latency. If designing a failover 
> connection, customer expectations may need to be managed: internet access may 
> be up, but will be noticeably degraded when on LTE. A backup cable connection 
> may be better for VoIP or other latency/jitter sensitive applications and of 
> course anything that relies on a static IP (server, vpn, etc) will probably 
> break if the primary connection is down. Would be a good idea to test the 
> failover connection during a few different time periods to gauge employee 
> experience.
> 
> —Blake

Yep. We sell solutions, both Cradlepoint and SD-WAN-based, and a big part of it 
is going over with the customer “you can’t just fail over all your regular 
traffic; pick biz-critical functions and deny everything else or you’re going 
to a) be very unhappy with speeds/performance and b) be EVEN MORE unhappy with 
the overage bill”. 

Get some data over a regular work week or so of their traffic, preferably with 
some flow data so you know what kinds of traffic/apps are consuming the 
bandwidth. Have the customer ID which of those flows would be critical if the 
primary connectivity died; size the cell plan appropriately or, if that can’t 
be done due to data caps, make sure needed tunnels for backoffice-type stuff 
will even work over your particular solution, etc... help them figure out what 
else can be dropped in an emergency. 

Other thing to consider is that almost all US cell plans have a pretty small 
data cap, even “unlimited”, and our testing shows that just backend Cradlepoint 
or SD-WAN chatter can add up to a GB or 2 a billing cycle; need to make sure 
your configs explicitly block any cellular usage unless the primary connection 
has gone completely down.

— 
Shawn

Re: Estimated LTE Data Utilization in Failover Scenario

[Blake Hudson]

Matt Harris wrote on 7/31/2019 9:46 AM:
On Wed, Jul 31, 2019 at 9:21 AM Shaun Dombrosky 
mailto:sdombro...@blackfoot.com>> wrote:


Good Morning,

First time NANOG poster, apologies if I breach etiquette.

Does anyone have any first-hand data on how much data a
small-medium business (SMB) can expect to consume in a failover
scenario over a 4G/LTE connection?  Retail, under 50 head count,
using PoS, maybe cloud accounting software, general internet
activity, 8 hour time period.  Wonder if anyone is using a
Cradlepoint or SD-WAN solution that could pull a few quick numbers
from a dashboard for me.  I haven’t had much luck in my searches.

Appreciate any info anyone can provide.

Thanks,


Hey Shaun,
I'd recommend pulling that data from the device normally facing their 
internet connection. Does it support netflow or even just basic snmp 
statistics that you could graph? Ostensibly the traffic level would be 
the same regardless of whether using an LTE backup connection or the 
primary internet connection unless you somehow prohibited certain 
traffic when on LTE. Ultimately though, your best bet is going to be 
to get real stats over the course of a couple of weeks and then you'll 
understand better the traffic patterns based on time of day, day of 
the week, etc, as well, as this is likely relevant.


Good luck!

100% agree with Matt. Something also to keep in mind is the SMB's peak 
data rates. The primary (I assume ethernet) uplink may have a sub 10ms 
latency and 100Mbps or greater data rate while the LTE connection is 
probably several times slower in terms of bandwidth and latency. If 
designing a failover connection, customer expectations may need to be 
managed: internet access may be up, but will be noticeably degraded when 
on LTE. A backup cable connection may be better for VoIP or other 
latency/jitter sensitive applications and of course anything that relies 
on a static IP (server, vpn, etc) will probably break if the primary 
connection is down. Would be a good idea to test the failover connection 
during a few different time periods to gauge employee experience.


--Blake

Re: Estimated LTE Data Utilization in Failover Scenario

[Matt Harris]

On Wed, Jul 31, 2019 at 9:21 AM Shaun Dombrosky 
wrote:

> Good Morning,
>
>
>
> First time NANOG poster, apologies if I breach etiquette.
>
>
>
> Does anyone have any first-hand data on how much data a small-medium
> business (SMB) can expect to consume in a failover scenario over a 4G/LTE
> connection?  Retail, under 50 head count, using PoS, maybe cloud accounting
> software, general internet activity, 8 hour time period.  Wonder if anyone
> is using a Cradlepoint or SD-WAN solution that could pull a few quick
> numbers from a dashboard for me.  I haven’t had much luck in my searches.
>
>
>
> Appreciate any info anyone can provide.
>
>
>
> Thanks,
>

Hey Shaun,
I'd recommend pulling that data from the device normally facing their
internet connection. Does it support netflow or even just basic snmp
statistics that you could graph? Ostensibly the traffic level would be the
same regardless of whether using an LTE backup connection or the primary
internet connection unless you somehow prohibited certain traffic when on
LTE. Ultimately though, your best bet is going to be to get real stats over
the course of a couple of weeks and then you'll understand better the
traffic patterns based on time of day, day of the week, etc, as well, as
this is likely relevant.

Good luck!

Re: Estimated LTE Data Utilization in Failover Scenario

[Matt Harris]

On Wed, Jul 31, 2019 at 9:21 AM Shaun Dombrosky 
wrote:

> Good Morning,
>
>
>
> First time NANOG poster, apologies if I breach etiquette.
>
>
>
> Does anyone have any first-hand data on how much data a small-medium
> business (SMB) can expect to consume in a failover scenario over a 4G/LTE
> connection?  Retail, under 50 head count, using PoS, maybe cloud accounting
> software, general internet activity, 8 hour time period.  Wonder if anyone
> is using a Cradlepoint or SD-WAN solution that could pull a few quick
> numbers from a dashboard for me.  I haven’t had much luck in my searches.
>
>
>
> Appreciate any info anyone can provide.
>
>
>
> Thanks,
>
>
>
> *Shaun Dombrosky*
> *Data Network Engineer*
>
>
>
>
>
> E: sdombro...@blackfoot.com
>
> *www.blackfoot.com  *
>
>
>
> Stay connected with Blackfoot:
>
>
>
> [image: cid:image001.png@01D2A238.12101D80]
> 
> [image: cid:image002.png@01D2A238.12101D80]
> 
>   [image: cid:image003.png@01D2A238.12101D80]
> 
>   [image: cid:image004.png@01D2A238.12101D80]
> 
>
>
>
>
>
> *This e-mail and any files transmitted with it are confidential and are
> intended solely for the use of the individual or entity to which they are
> addressed.  If you are not the intended recipient or the person responsible
> for delivering the e-mail to the intended recipient, be advised that you
> have received this e-mail in error and that any use, dissemination,
> forwarding, printing, or copying of this e-mail is strictly prohibited. If
> you have received this e-mail in error, please immediately reply to the
> sender by email notifying them of the error and delete the original and
> reply copies. Thank you.*
>
>
>


-- 
Matt Harris - Chief Security Officer
Security, Compliance, and Engineering
Main: +1-816-256-5446
Mobile: +1-908-590-9472
Email: m...@netfire.net

email delays from Google

[Trey Nolen]

We have been experiencing delays / failures receiving email from domains 
hosted by Google and *only* domains hosted by Google.


This is happening to customers for whom we host the authoritative DNS 
servers.   For some reason, Google is not able to look up the MX and/or 
A record *sometimes* from our servers.


Customers are getting an error like this:
--BEGIN
DNS Error: 49391460 DNS type ‘mx’ lookup of  
responded with code NOERROR 49391460 DNS type ‘’ lookup of 
mail.internetpro.net . responded with code 
SERVFAIL 49391460 DNS type ‘a’ lookup of mail.internetpro.net 
. responded with code SERVFAIL


--END

In the above case, Google is saying they can't find our mail server.  
There is no  record, so that part is normal.


However, we have other customers who are hosting their own mail servers 
or are using relay services such as Trend Micro who are also having a 
similar issue.  The only thing these customers have in common is our DNS 
and the fact that Google is trying to send email to them.


I can query Google's public servers at 8.8.8.8 and 8.8.4.4 and they 
always give the correct answers, but it seems that internally, Google is 
unable to make these lookups.   Reaching out to their support agents 
online, the agents confirm that the correct entries are in place and 
that *some* of Google's servers can't do the resolution resulting in 
sporadic email delivery.  They suggest that we reach out to the DNS 
provider to find out why (Grrr)


We've also had reports from customers that the failures seem to be 
location oriented with western US emails being held up and eastern US 
emails coming through.  I can't independently confirm that, though.


A full 100% of the email delivery issues have been Google hosted 
domains.   It seems that every other ISP can do the lookups just fine, 
but getting in touch with someone at Google who can troubleshoot this is 
impossible for a small ISP like us.


If anyone can point me to somone at Google who could help me out, I'd be 
very thankful.



Trey Nolen

Re: User Unknown (WAS: really amazon?)

[Steve Pointer]

> OK, I'll bite.  What reasons are they giving for their resistance? (And 
> if known,
> what are the *real* reasons if different?)

https://www.ripe.net/ripe/mail/archives/ncc-services-wg/2018-October/thread.html
 

--
Steve P

Estimated LTE Data Utilization in Failover Scenario

[Shaun Dombrosky]

Good Morning,

First time NANOG poster, apologies if I breach etiquette.

Does anyone have any first-hand data on how much data a small-medium business 
(SMB) can expect to consume in a failover scenario over a 4G/LTE connection?  
Retail, under 50 head count, using PoS, maybe cloud accounting software, 
general internet activity, 8 hour time period.  Wonder if anyone is using a 
Cradlepoint or SD-WAN solution that could pull a few quick numbers from a 
dashboard for me.  I haven't had much luck in my searches.

Appreciate any info anyone can provide.

Thanks,

Shaun Dombrosky
Data Network Engineer

[cid:image001.png@01D546BC.019D2710]

E: sdombro...@blackfoot.com
www.blackfoot.com

Stay connected with Blackfoot:

[cid:image001.png@01D2A238.12101D80]
  [cid:image002.png@01D2A238.12101D80] 

   [cid:image003.png@01D2A238.12101D80] 

   [cid:image004.png@01D2A238.12101D80] 



This e-mail and any files transmitted with it are confidential and are intended 
solely for the use of the individual or entity to which they are addressed.  If 
you are not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, be advised that you have received this e-mail 
in error and that any use, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you have received this e-mail in error, 
please immediately reply to the sender by email notifying them of the error and 
delete the original and reply copies. Thank you.

Re: User Unknown (WAS: really amazon?)

[Scott Christopher]

John Curran wrote: 

> Scott - 
> 
> Alas, you have a fundamental misunderstanding about the nature of ARIN… we 
> don’t do anything other than implement policies that this community wants. If 
> the community developed a policy to require Abuse POC’s validation, and said 
> policy made clear that failure to do so was to result in revocation, then 
> ARIN would indeed implement the policy (and that includes revocation for 
> those who ignored the policy.) 

Hello John - you are absolutely right. Since the community has shown 
overwhelming disapproval of Amazon's invalid abuse POC, please go ahead and 
revoke Amazon's resources.

Maybe do this late Friday afternoon for the courtesy toward Amazon's support 
staff ?

And since this will certainly be historic, please post an announcement to 
nanog-list ?

Thanks, and Good luck !

S.C.

Re: really amazon?

[Rich Kulawiec]

Yes, this is egregious, but on the other hand even when the abuse
reporting mechanisms are working my experience has been that they
emit no response (other than -- maybe -- boilerplate) and take no
action, so it's not terribly surprising.

---rsk

Re: User Unknown (WAS: really amazon?)

[Töma Gavrichenkov]

On Wed, Jul 31, 2019 at 4:04 PM Töma Gavrichenkov  wrote:
> > OK, I'll bite.  What reasons are they giving for their resistance?
>
> Here's a good place to start: https://ripe78.ripe.net/archives/steno/37/
> ^F, "You're done", enjoy!

P.S. Suddenly there's an important mistake in the transcript: the
boiling frog argument was introduced by Piotr Strzyzewski (RIPE NCC
Exec Board), not Petr Špaček (CZ.NIC). Slavic names are always a
challenge for scribes (look up "grzegorz brzęczyszczykiewicz" on
Youtube).

--
Töma

Re: User Unknown (WAS: really amazon?)

[Töma Gavrichenkov]

On Wed, Jul 31, 2019 at 3:35 PM Valdis Klētnieks
 wrote:
>
> On Tue, 30 Jul 2019 16:02:58 +0300, Töma Gavrichenkov said:
> > such a policy (2019-04) is still in a discussion
> > phase in RIPE and has already seen significant resistance.
>
> OK, I'll bite.  What reasons are they giving for their resistance?

Here's a good place to start: https://ripe78.ripe.net/archives/steno/37/
^F, "You're done", enjoy!

--
Töma

Re: User Unknown (WAS: really amazon?)

[Valdis Klētnieks]

On Tue, 30 Jul 2019 16:02:58 +0300, T�ma Gavrichenkov said:
> On Tue, Jul 30, 2019 at 1:20 PM Christoffer Hansen  
> wrote:
> > Imagine ARIN did a take from RIPE NCC [Policy Proposal Idea?] and a
> > policy came into effect of validating ALL 'OrgAbuseEmail' objects listed
> > in the ARIN database.
>
> Just to be precise, such a policy (2019-04) is still in a discussion
> phase in RIPE and has already seen significant resistance.

OK, I'll bite.  What reasons are they giving for their resistance? (And if 
known,
what are the *real* reasons if different?)



pgpizK0HBpOwX.pgp
Description: PGP signature