Re: CloudFlare Issues?

[John Von Essen]

Did anyone see any collateral damage from this outside of Cloudflare? 
Specifically Azure?

I manage a very large site in Azure, and at the exact same time of the 
Cloudflare incident we saw a spike in traffic (like a DDoS or Bot), then 
followed by unusual hardware resource anomalies. We’re globally spread in 
Azure, but we only saw this in the US and Brazil.

Very coincidental, but possible.


-John

> On Jul 17, 2020, at 5:33 PM, Aaron C. de Bruyn via NANOG  
> wrote:
> 
> More digging shows high latency to CloudFlare DNS servers from Comcast in 
> Washington and Oregon as well as a few other providers (Charter, ToledoTel), 
> etc...
> 
> Sites that do resolve using other DNS servers but are hosted on CloudFlare 
> aren't loading.
> Sites that use CloudFlare for their DNS aren't resolving either.
> traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
> 
>  1  _gateway (192.168.42.254)  0.185 ms  0.109 ms  0.117 ms
>  2  pppoe-gw-208-70-52.toledotel.com 
>  (208.70.52.1)  1.896 ms  1.881 ms  
> 1.903 ms
>  3  tuk-edge-13.inet.qwest.net  
> (198.233.244.225)  4.158 ms  4.082 ms  4.071 ms
>  4  sea-brdr-03.inet.qwest.net  
> (67.14.41.154)  8.976 ms  8.949 ms  8.903 ms
>  5  * * *
>  6  ae-1-51.ear2.Seattle1.Level3.net 
>  (4.69.203.173)  4.494 ms  4.350 ms 
>  4.311 ms
>  7  4.53.154.10 (4.53.154.10)  77.622 ms  103.323 ms  103.240 ms
>  8  * * *
>  9  * * *
> 10  * * *
> 11  * * *
> 12  * * *
> 13  one.one.one.one (1.1.1.1)  87.515 ms * *
> 
> -A
> 
> On Fri, Jul 17, 2020 at 2:18 PM Aaron C. de Bruyn  > wrote:
> Anyone seeing Cloudflare DNS outages or site issues?
> 
> Affecting a bunch of sites in Washington and Oregon.
> 
> -A



smime.p7s
Description: S/MIME cryptographic signature

Re: CloudFlare Issues?

[Chris Adams]

Once upon a time, Peter Kristolaitis  said:
> Cloudflare's status page acknowledged a recursive DNS issue as of a
> few minutes ago.  Lots of reports of problems on the Outages list
> and Reddit.

It was not just recursive - authoritative DNS on Cloudflare servers also
did not respond.
-- 
Chris Adams 

Re: MX204 Rails

[Steven Karp]

I tried the Juniper EX-4PST-RMK Kit and the holes do not line up with the MX204.

Sent from my mobile device

> On Jul 17, 2020, at 2:52 PM, Travis Garrison  wrote:
> 
> We have used these (purchased from ebay) as universal rails for different 
> products. Seemed a bit better than a shelf.
> 
> https://www.apc.com/shop/us/en/products/APC-4-Post-Rackmount-Rails/P-SU032A
> 
> Thanks Travis
> 
> -Original Message-
> From: NANOG  On Behalf Of 
> Cory Andrews
> Sent: Thursday, July 16, 2020 2:48 PM
> To: nanog@nanog.org
> Subject: Re: MX204 Rails
> 
> Have you tried the Juniper EX-4PST-RMK Rail Kit?  It is listed as compatible 
> with Juniper EX and QFX compatible, but appears to be potentially the same as 
> the slide rail kit that comes with the MX series devices.
> 
> Cory J Andrews
> NetEquity.com
> 793 Center St. #551
> Lewiston, NY 14092
> 877-582-4726 TF/FAX
> 
>> On 7/16/2020 3:37 PM, Simon Lockhart wrote:
>>> On Thu Jul 16, 2020 at 02:27:25PM -0500, Rafael Possamai wrote:
>>> Doesn't the mx204 have rackmount brackets rather than rails?
>> It has ears at the front, and "rails" at the rear.
>> 
>> The MX204 would have come with the rear rails when bought new.
>> 
>> See 
>> https://www.juniper.net/documentation/en_US/release-independent/junos/
>> topics/topic-map/mx204-installing.html
>> 
>> Simon

Re: CloudFlare Issues?

[Justin Paine via NANOG]

The team is working on it.

_
*Justin Paine*
Head of Trust & Safety
PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D

101 Townsend St., San Francisco, CA 94107



On Fri, Jul 17, 2020 at 2:53 PM  wrote:

> Chris Grundemann wrote on 7/17/2020 2:38 PM:
>
> Looks like there may be something big up (read: down) at CloudFlare, but
> their status page is not reporting anything yet.
>
> Am I crazy? Or just time to give up on the internet for this week?
>
> --
> @ChrisGrundemann
> http://chrisgrundemann.com
>
> Status page just updated: Edge network and resolver issues.
>
> We had noticed something was up on our network as well w/ IPv6 name
> resolution timing out for some sites.
>
>
>

CloudFlare Issues?

[Aaron C. de Bruyn via NANOG]

Anyone seeing Cloudflare DNS outages or site issues?

Affecting a bunch of sites in Washington and Oregon.

-A

Re: CloudFlare Issues?

[Coy Hile]

> On Jul 17, 2020, at 5:38 PM, Chris Grundemann  wrote:
> 
> Looks like there may be something big up (read: down) at CloudFlare, but 
> their status page is not reporting anything yet.
> 
> Am I crazy? Or just time to give up on the internet for this week?
> 
> 

You’re not crazy. I’m seeing the same behavior (still unable to get back into a 
few Discord servers) from Comcast in the Philly area. 

--
Coy Hile
coy.h...@coyhile.com

Re: CloudFlare Issues?

[Aaron C. de Bruyn via NANOG]

CloudFlare updated their status page and confirmed the issue:

https://www.cloudflarestatus.com/

-A

On Fri, Jul 17, 2020 at 2:33 PM Aaron C. de Bruyn 
wrote:

> More digging shows high latency to CloudFlare DNS servers from Comcast in
> Washington and Oregon as well as a few other providers (Charter,
> ToledoTel), etc...
>
> Sites that do resolve using other DNS servers but are hosted on CloudFlare
> aren't loading.
> Sites that use CloudFlare for their DNS aren't resolving either.
> traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
>
>  1  _gateway (192.168.42.254)  0.185 ms  0.109 ms  0.117 ms
>  2  pppoe-gw-208-70-52.toledotel.com (208.70.52.1)  1.896 ms  1.881 ms
>  1.903 ms
>  3  tuk-edge-13.inet.qwest.net (198.233.244.225)  4.158 ms  4.082 ms
>  4.071 ms
>  4  sea-brdr-03.inet.qwest.net (67.14.41.154)  8.976 ms  8.949 ms  8.903
> ms
>  5  * * *
>  6  ae-1-51.ear2.Seattle1.Level3.net (4.69.203.173)  4.494 ms  4.350 ms
>  4.311 ms
>  7  4.53.154.10 (4.53.154.10)  77.622 ms  103.323 ms  103.240 ms
>  8  * * *
>  9  * * *
> 10  * * *
> 11  * * *
> 12  * * *
> 13  one.one.one.one (1.1.1.1)  87.515 ms * *
>
> -A
>
> On Fri, Jul 17, 2020 at 2:18 PM Aaron C. de Bruyn 
> wrote:
>
>> Anyone seeing Cloudflare DNS outages or site issues?
>>
>> Affecting a bunch of sites in Washington and Oregon.
>>
>> -A
>>
>

Re: CloudFlare Issues?

[Dave Phelps]

 From cloudflarestatus.com

Cloudflare Network and Resolver Issues

*Investigating* - Cloudflare is investigating issues with Cloudflare
Resolver and our edge network in certain locations.

Customers using Cloudflare services in certain regions are impacted as
requests might fail and/or errors may be displayed.

Data Centers impacted include: SJC, DFW, SEA, LAX, ORD, IAD, EWR, ATL, LHR,
AMS, FRA, CDG

On Fri, Jul 17, 2020 at 4:44 PM Dave Phelps  wrote:

> Cloudlflare's status page shows they are investigating an issue. Discord's
> status page also shows Cloudflare has an issue. Most people aren't making
> the Cloudflare connection yet and reporting many other services down
> instead.
>
> On Fri, Jul 17, 2020 at 4:40 PM Chris Grundemann 
> wrote:
>
>> Looks like there may be something big up (read: down) at CloudFlare, but
>> their status page is not reporting anything yet.
>>
>> Am I crazy? Or just time to give up on the internet for this week?
>>
>> --
>> @ChrisGrundemann
>> http://chrisgrundemann.com
>>
>

Re: CloudFlare Issues?

[Dave Phelps]

Cloudlflare's status page shows they are investigating an issue. Discord's
status page also shows Cloudflare has an issue. Most people aren't making
the Cloudflare connection yet and reporting many other services down
instead.

On Fri, Jul 17, 2020 at 4:40 PM Chris Grundemann 
wrote:

> Looks like there may be something big up (read: down) at CloudFlare, but
> their status page is not reporting anything yet.
>
> Am I crazy? Or just time to give up on the internet for this week?
>
> --
> @ChrisGrundemann
> http://chrisgrundemann.com
>

Re: CloudFlare Issues?

[Peter Kristolaitis]

Cloudflare's status page acknowledged a recursive DNS issue as of a few 
minutes ago.  Lots of reports of problems on the Outages list and Reddit.


From their status page:

*Investigating*- Cloudflare is investigating issues with Cloudflare 
Resolver and our edge network in certain locations.


Customers using Cloudflare services in certain regions are impacted as 
requests might fail and/or errors may be displayed.


Data Centers impacted include: SJC, DFW, SEA, LAX, ORD, IAD, EWR, ATL, 
LHR, AMS, FRA, CDG

Jul17,21:37UTC


On 2020-07-17 5:38 p.m., Chris Grundemann wrote:
Looks like there may be something big up (read: down) at CloudFlare, 
but their status page is not reporting anything yet.


Am I crazy? Or just time to give up on the internet for this week?

--
@ChrisGrundemann
http://chrisgrundemann.com

RE: CloudFlare Issues?

[Spencer Coplin]

My sites appear to be normal. Maybe it’s time for happy hour?

Thank you,
Spencer

From: NANOG  On Behalf Of 
Chris Grundemann
Sent: Friday, July 17, 2020 4:39 PM
To: NANOG list 
Subject: CloudFlare Issues?

CAUTION: This email originated from an external source. Verify the sender 
before taking any actions.

Looks like there may be something big up (read: down) at CloudFlare, but their 
status page is not reporting anything yet.

Am I crazy? Or just time to give up on the internet for this week?

--
@ChrisGrundemann
http://chrisgrundemann.com

Re: CloudFlare Issues?

[blakangel]

Chris Grundemann wrote on 7/17/2020 2:38 PM:

Looks like there may be something big up (read: down) at CloudFlare, 
but their status page is not reporting anything yet.


Am I crazy? Or just time to give up on the internet for this week?

--
@ChrisGrundemann
http://chrisgrundemann.com

Status page just updated: Edge network and resolver issues.

We had noticed something was up on our network as well w/ IPv6 name 
resolution timing out for some sites.

RE: CloudFlare Issues?

[Kody Vicknair]

https://www.cloudflarestatus.com/


From: NANOG  On Behalf Of 
Chris Grundemann
Sent: Friday, July 17, 2020 4:39 PM
To: NANOG list 
Subject: CloudFlare Issues?

*External Email: Use Caution*
Looks like there may be something big up (read: down) at CloudFlare, but their 
status page is not reporting anything yet.

Am I crazy? Or just time to give up on the internet for this week?

--
@ChrisGrundemann
https://link.edgepilot.com/s/f7346db5/qDrwfqlG4ESjtP0RY1EKXQ?u=http://chrisgrundemann.com/


Links contained in this email have been replaced. If you click on a link in the 
email above, the link will be analyzed for known threats. If a known threat is 
found, you will not be able to proceed to the destination. If suspicious 
content is detected, you will see a warning.

Re: CloudFlare Issues?

[Rob McEwen]

I think they were down for about 30 or so minutes, but came back up 
right about the time you hit the send button

--Rob McEwen

On 7/17/2020 5:38 PM, Chris Grundemann wrote:
Looks like there may be something big up (read: down) at CloudFlare, 
but their status page is not reporting anything yet.


Am I crazy? Or just time to give up on the internet for this week?

--
@ChrisGrundemann
http://chrisgrundemann.com



--
Rob McEwen
invaluement

Re: CloudFlare Issues?

[Aaron C. de Bruyn via NANOG]

More digging shows high latency to CloudFlare DNS servers from Comcast in
Washington and Oregon as well as a few other providers (Charter,
ToledoTel), etc...

Sites that do resolve using other DNS servers but are hosted on CloudFlare
aren't loading.
Sites that use CloudFlare for their DNS aren't resolving either.
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets

 1  _gateway (192.168.42.254)  0.185 ms  0.109 ms  0.117 ms
 2  pppoe-gw-208-70-52.toledotel.com (208.70.52.1)  1.896 ms  1.881 ms
 1.903 ms
 3  tuk-edge-13.inet.qwest.net (198.233.244.225)  4.158 ms  4.082 ms  4.071
ms
 4  sea-brdr-03.inet.qwest.net (67.14.41.154)  8.976 ms  8.949 ms  8.903 ms
 5  * * *
 6  ae-1-51.ear2.Seattle1.Level3.net (4.69.203.173)  4.494 ms  4.350 ms
 4.311 ms
 7  4.53.154.10 (4.53.154.10)  77.622 ms  103.323 ms  103.240 ms
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  one.one.one.one (1.1.1.1)  87.515 ms * *

-A

On Fri, Jul 17, 2020 at 2:18 PM Aaron C. de Bruyn 
wrote:

> Anyone seeing Cloudflare DNS outages or site issues?
>
> Affecting a bunch of sites in Washington and Oregon.
>
> -A
>

CloudFlare Issues?

[Chris Grundemann]

Looks like there may be something big up (read: down) at CloudFlare, but
their status page is not reporting anything yet.

Am I crazy? Or just time to give up on the internet for this week?

-- 
@ChrisGrundemann
http://chrisgrundemann.com

Re: Wifi Calling Firewall Holes to Punch

[Jason Alderfer]

In our university environment, wifi calling works just fine over NAT and
we have not made any inbound port exceptions in the firewall for it.  The
critical piece for (non-enterprise) VoIP traffic is that your firewall must
not try to function as a SIP ALG, but I'm not sure that's directly relevant
to wifi calling for the major carriers.

Jason Alderfer
Director of Technology SystemsEastern Mennonite University


On Fri, Jul 17, 2020 at 12:40 PM Lyden, John C  wrote:

> Hey gang.
>
>
>
> We’re setting up a unified wireless network for the students here, and to
> get around the issues with Nintendo and NAT we devoted a large chunk of
> public IP space to them.
>
>
>
> We’re aware that this is causing issues with wifi calling on Verizon, TMo
> etc because it appears they initiate the SIP session inbound.
>
>
>
> Does anybody have a handy list of IP blocks and ports? T-Mobile had a
> decent page but other providers just said “open up 4500 and 500” and our
> ISO guys don’t like that.
>
>
>
> Thanks if someone can help.
>
>
>
> John C. Lyden
>
> Manager of Network Infrastructure, Infrastructure Services
>
> Division of Information Resources & Technology, Rowan University
>
>
>

Re: Wifi Calling Firewall Holes to Punch

[Mark Tinka]

On 17/Jul/20 22:09, Josh Luthman wrote:
> I do dozens of VZW WiFi calls a day.  My phone is behind NAT, no problem.
>
> It's probably 50/50 where the call starts on WiFi vs switches to WiFi
> after ~3 seconds from the poor VZW signal.

Same here, one of my cell operators uses VoWiFi for their calls and SMS's.

As long as I am on wi-fi though, all calls and SMS's are sent over wi-fi.

I'm doing NAT44 + native IPv6, no special holes punched in my Mikrotik
router (the cell provider is doing WiFi Calling over IPv4).

Mark.

Re: Wifi Calling Firewall Holes to Punch

[Josh Luthman]

I do dozens of VZW WiFi calls a day.  My phone is behind NAT, no problem.

It's probably 50/50 where the call starts on WiFi vs switches to WiFi after
~3 seconds from the poor VZW signal.

Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373


On Fri, Jul 17, 2020 at 12:59 PM Alex Buie via NANOG 
wrote:

> It's been a minute since I've set this up in a corp/campus wifi scenario,
> but my notes for Verizon VoWiFi  from the last time I did say that you need
> outbound udp/500 and udp/4500 IPSec protocol (IKE and ESP) permitted out
> the firewall. Tunnel endpoints live in 141.207.0.0/16, so hopefully that
> lets you scope the rule enough to please your ISO.
>
> Devices will also need the ability to make an HTTPS request to
> https://spg.vzw.com/SSFGateway/e911Location/changeAddress
>
> As well, DNS queries for the ePDG domain wo.vzwwo.com need to be
> permitted.
>
> That _should_ be all you need to get it bootstrapped.
>
> Alex
>
> On Fri, Jul 17, 2020 at 12:39 PM Lyden, John C  wrote:
>
>> Hey gang.
>>
>>
>>
>> We’re setting up a unified wireless network for the students here, and to
>> get around the issues with Nintendo and NAT we devoted a large chunk of
>> public IP space to them.
>>
>>
>>
>> We’re aware that this is causing issues with wifi calling on Verizon, TMo
>> etc because it appears they initiate the SIP session inbound.
>>
>>
>>
>> Does anybody have a handy list of IP blocks and ports? T-Mobile had a
>> decent page but other providers just said “open up 4500 and 500” and our
>> ISO guys don’t like that.
>>
>>
>>
>> Thanks if someone can help.
>>
>>
>>
>> John C. Lyden
>>
>> Manager of Network Infrastructure, Infrastructure Services
>>
>> Division of Information Resources & Technology, Rowan University
>>
>>
>>
>
>
> --
> *Alex Buie*
> Associate Network Engineer
> Datto, Inc.
> 475-288-4550 (o)
> 585-653-8779 (c)
> www.datto.com
>
> 
>
> Join the conversation! [image: Facebook]
>   [image: Twitter]
>  [image: LinkedIn]
>   [image: Blog RSS]
>  [image: Slideshare]
>   [image: Spiceworks]
> 
>

RE: MX204 Rails

[Travis Garrison]

We have used these (purchased from ebay) as universal rails for different 
products. Seemed a bit better than a shelf.

https://www.apc.com/shop/us/en/products/APC-4-Post-Rackmount-Rails/P-SU032A

Thanks Travis

-Original Message-
From: NANOG  On Behalf Of Cory 
Andrews
Sent: Thursday, July 16, 2020 2:48 PM
To: nanog@nanog.org
Subject: Re: MX204 Rails

Have you tried the Juniper EX-4PST-RMK Rail Kit?  It is listed as compatible 
with Juniper EX and QFX compatible, but appears to be potentially the same as 
the slide rail kit that comes with the MX series devices.

Cory J Andrews
NetEquity.com
793 Center St. #551
Lewiston, NY 14092
877-582-4726 TF/FAX

On 7/16/2020 3:37 PM, Simon Lockhart wrote:
> On Thu Jul 16, 2020 at 02:27:25PM -0500, Rafael Possamai wrote:
>> Doesn't the mx204 have rackmount brackets rather than rails?
> It has ears at the front, and "rails" at the rear.
>
> The MX204 would have come with the rear rails when bought new.
>
> See 
> https://www.juniper.net/documentation/en_US/release-independent/junos/
> topics/topic-map/mx204-installing.html
>
> Simon

Verizon FIOS DNS contact?

[Jim Bonnet via NANOG]

Hi Folks,

Is there a contact I could chat with regarding fios dns not resolving one
of our domains correctly.

DNS servers in question are
71.252.0.12
71.252.0.14

Those servers are doing the NXDOMAIN redirect(searchassistant) to a domain
that does exist.

Ping me offlist please.

Thank you for your time.

-- 
Jim Bonnet
Broadcom SED


smime.p7s
Description: S/MIME Cryptographic Signature

Weekly Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG
TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 18 Jul, 2020

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  817116
Prefixes after maximum aggregation (per Origin AS):  310311
Deaggregation factor:  2.63
Unique aggregates announced (without unneeded subnets):  392801
Total ASes present in the Internet Routing Table: 68665
Prefixes per ASN: 11.90
Origin-only ASes present in the Internet Routing Table:   58982
Origin ASes announcing only one prefix:   24577
Transit ASes present in the Internet Routing Table:9683
Transit-only ASes present in the Internet Routing Table:296
Average AS path length visible in the Internet Routing Table:   4.4
Max AS path length visible:  43
Max AS path prepend of ASN ( 22394)  38
Prefixes from unregistered ASNs in the Routing Table:   889
Number of instances of unregistered ASNs:   890
Number of 32-bit ASNs allocated by the RIRs:  32542
Number of 32-bit ASNs visible in the Routing Table:   26839
Prefixes from 32-bit ASNs in the Routing Table:  123768
Number of bogon 32-bit ASNs visible in the Routing Table:14
Special use prefixes present in the Routing Table:1
Prefixes being announced from unallocated address space:584
Number of addresses announced to Internet:   2845076224
Equivalent to 169 /8s, 148 /16s and 107 /24s
Percentage of available address space announced:   76.8
Percentage of allocated address space announced:   76.8
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   99.5
Total number of prefixes smaller than registry allocations:  276341

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   213888
Total APNIC prefixes after maximum aggregation:   62741
APNIC Deaggregation factor:3.41
Prefixes being announced from the APNIC address blocks:  207605
Unique aggregates announced from the APNIC address blocks:86091
APNIC Region origin ASes present in the Internet Routing Table:   10740
APNIC Prefixes per ASN:   19.33
APNIC Region origin ASes announcing only one prefix:   3027
APNIC Region transit ASes present in the Internet Routing Table:   1594
Average APNIC Region AS path length visible:4.7
Max APNIC Region AS path length visible: 28
Number of APNIC region 32-bit ASNs visible in the Routing Table:   5817
Number of APNIC addresses announced to Internet:  768689536
Equivalent to 45 /8s, 209 /16s and 69 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-141625
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:238903
Total ARIN prefixes after maximum aggregation:   109576
ARIN Deaggregation factor: 2.18
Prefixes being announced from the ARIN address blocks:   236275
Unique aggregates announced from the ARIN address blocks:115345
ARIN Region origin ASes present in the Internet Routing Table:18530
ARIN Prefixes per ASN:12.75
ARIN 

Re: Wifi Calling Firewall Holes to Punch

[Alex Buie via NANOG]

It's been a minute since I've set this up in a corp/campus wifi scenario,
but my notes for Verizon VoWiFi  from the last time I did say that you need
outbound udp/500 and udp/4500 IPSec protocol (IKE and ESP) permitted out
the firewall. Tunnel endpoints live in 141.207.0.0/16, so hopefully that
lets you scope the rule enough to please your ISO.

Devices will also need the ability to make an HTTPS request to
https://spg.vzw.com/SSFGateway/e911Location/changeAddress

As well, DNS queries for the ePDG domain wo.vzwwo.com need to be permitted.

That _should_ be all you need to get it bootstrapped.

Alex

On Fri, Jul 17, 2020 at 12:39 PM Lyden, John C  wrote:

> Hey gang.
>
>
>
> We’re setting up a unified wireless network for the students here, and to
> get around the issues with Nintendo and NAT we devoted a large chunk of
> public IP space to them.
>
>
>
> We’re aware that this is causing issues with wifi calling on Verizon, TMo
> etc because it appears they initiate the SIP session inbound.
>
>
>
> Does anybody have a handy list of IP blocks and ports? T-Mobile had a
> decent page but other providers just said “open up 4500 and 500” and our
> ISO guys don’t like that.
>
>
>
> Thanks if someone can help.
>
>
>
> John C. Lyden
>
> Manager of Network Infrastructure, Infrastructure Services
>
> Division of Information Resources & Technology, Rowan University
>
>
>


-- 
*Alex Buie*
Associate Network Engineer
Datto, Inc.
475-288-4550 (o)
585-653-8779 (c)
www.datto.com



Join the conversation! [image: Facebook] 
  [image: Twitter]  [image: LinkedIn]
  [image: Blog RSS]
 [image: Slideshare]
  [image: Spiceworks]

Re: BFD for long haul circuit

[Mark Tinka]

On 17/Jul/20 18:42, Tom Hill wrote:

> Yes, I rather think that you've drawn comparison to "consumer" as being
> in a home somewhere.
>
> Someone that consumes a circuit, and someone that provides the service
> (or resells one). A business customer is a consumer in that case - I
> won't discriminate against what use someone has for wanting to consume
> bandwidth between countries, but I do think the specificity here is in
> whether you intend to just use it, or resell it, and that's where the
> difference comes in relation to Robert's point.

We see both use-cases, where businesses (enterprise) consume, and
operators resell.

Ultimately, it's about not boxing everything into a definition,
especially if it meets your needs. Just like how our idea of a core or
peering router vs. a vendor's idea of a core or peering router might
differ :-).

Mark.

Re: BFD for long haul circuit

[Tom Hill]

On 17/07/2020 16:40, Mark Tinka wrote:
> I don't know of "Consumers" that buy l2vpn's. Most consumers usually go
> for ADSL, FTTH or 4G... all carrying IP :-).
> 
> We have several customers that buy EoMPLS circuits from us both within
> and outside of countries, and between continents. The reasons vary, but
> safe to say they've been happy.

Yes, I rather think that you've drawn comparison to "consumer" as being
in a home somewhere.

Someone that consumes a circuit, and someone that provides the service
(or resells one). A business customer is a consumer in that case - I
won't discriminate against what use someone has for wanting to consume
bandwidth between countries, but I do think the specificity here is in
whether you intend to just use it, or resell it, and that's where the
difference comes in relation to Robert's point.

-- 
Tom

Wifi Calling Firewall Holes to Punch

[Lyden, John C]

Hey gang.

We're setting up a unified wireless network for the students here, and to get 
around the issues with Nintendo and NAT we devoted a large chunk of public IP 
space to them.

We're aware that this is causing issues with wifi calling on Verizon, TMo etc 
because it appears they initiate the SIP session inbound.

Does anybody have a handy list of IP blocks and ports? T-Mobile had a decent 
page but other providers just said "open up 4500 and 500" and our ISO guys 
don't like that.

Thanks if someone can help.

John C. Lyden
Manager of Network Infrastructure, Infrastructure Services
Division of Information Resources & Technology, Rowan University

RE: BFD for long haul circuit

[Harivishnu Abhilash]

Classification:Internal

Hi Mark,

Thanks for the update. You have any backhauls, that is running over an L2 
xconnect  ? I’m facing issue only on the backhaul link over a l2vpn ckt.

Ta,


From: NANOG  On 
Behalf Of Mark Tinka
Sent: Thursday, July 16, 2020 8:35 PM
To: nanog@nanog.org
Subject: Re: BFD for long haul circuit

EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust 
the sender and know the content is safe.


On 16/Jul/20 05:51, Harivishnu Abhilash wrote:
Classification:Public

Guys, I’m looking for recommendation regarding BFD timers that we can use for 
long haul circuit. RTT is roughly around 110 ms. In fact this is a l2vpn ckt 
provided by a telco.
Can you please advise the factors we can consider when setting the BFD timers 
(or any recommended values)? I have set 10 ms dead time but this is causing BFD 
to go down occasionally.

We run different intervals and multipliers depending on whether the connection 
is LAN or WAN.

For LAN (so within the same data centre), intervals are set to 150ms and 
multipliers are set to 3.

For WAN (any backbone regardless of latency), intervals are set to 250ms and 
multipliers are set to 5.

Since our network spans multiple countries and continents, we wanted a uniform 
value for the WAN side of things, so we don't have too many customized 
configurations. We found these settings to work well in mixed environments 
where implementations vary between CPU and line card processing, and also to 
strike a balance between accuracy and false positives.

We've been running this on IOS XE, IOS XR and Junos platforms since 2014. The 
only issues we found were:

  *   BFD on LAG's on IOS XR platforms in a LAN environment don't work. A 
point-to-point mechanism is required, so we disabled it there. Junos and IOS XE 
have no problems running BFD on LAG's in LAN's, so we have it on there. This is 
for within the data centre.

  *   BFDv6 on the MX does not run in hardware. Since IS-IS (for us) ties in 
BFD for link state event detection, a transient lack of CPU resources to 
service BFDv6 traffic will result in not only BFDv6 going down, but also the 
entire IS-IS protocol flapping on the assumption that a link event has 
occurred. So if you run BFDv6 alongside BFDv4, recommend that you disable BFDv6 
until Juniper introduce hardware support for it on the MX (and I'm guessing all 
other Junos platforms). We have an ER out for this since 2019, and we are told 
it should be appearing sometime between Q4'20 - 1H'21.

  *   Syntax for BFD in Junos has changed to incorporate address families. So 
while the old syntax will commit, it will leave an annotation in the 
configuration about not being supported anymore. Recommend you convert your 
Junos BFD configurations to IPv4 and IPv6 specificity, if you haven't already 
done so. I can't remember when this came into effect, but it likely was Junos 
16. We are on Junos 17 now.

Our longest circuit point-to-point is 140ms (Cape Town - London). These 
settings have been running fine on there since Day 1 (IOS XR-to-IOS XR), and 
overall detection and re-convergence of IS-IS + LFA leaves us happy and 
sleeping well at night.

Mark.


This email is classified as Internal by Harivishnu Abhilash
Disclaimer: This electronic message and all contents contain information from 
Mannai Corporation which may be privileged, confidential or otherwise protected 
from discloser. The information is intended to be for the addressee only. If 
you are not addressee, any disclosure, copy, distribution or use of the 
contents of this message is prohibited. If you have received this electronic 
message in error please notify the sender immediately and destroy the original 
and all copies.

Re: MX204 Rails

[Cory Andrews]

Have you tried the Juniper EX-4PST-RMK Rail Kit?  It is listed as 
compatible with Juniper EX and QFX compatible, but appears to be 
potentially the same as the slide rail kit that comes with the MX series 
devices.


Cory J Andrews
NetEquity.com
793 Center St. #551
Lewiston, NY 14092
877-582-4726 TF/FAX

On 7/16/2020 3:37 PM, Simon Lockhart wrote:

On Thu Jul 16, 2020 at 02:27:25PM -0500, Rafael Possamai wrote:

Doesn't the mx204 have rackmount brackets rather than rails?

It has ears at the front, and "rails" at the rear.

The MX204 would have come with the rear rails when bought new.

See 
https://www.juniper.net/documentation/en_US/release-independent/junos/topics/topic-map/mx204-installing.html

Simon

Re: BFD for long haul circuit

[Mark Tinka]

On 17/Jul/20 17:12, Nick Hilliard wrote:

>
> I was going to suggest that there wasn't much in the way of consumer
> grade international circuits, so why would you even bring this up? 
> But then I lol'd.

Now you have me wondering whether Tom was serious or not :-).

It's time for my Friday wine, hehe.

Mark.

Re: BFD for long haul circuit

[Mark Tinka]

On 17/Jul/20 17:06, Tom Hill wrote:

> The differentiation is: consumer vs. service provider.
>
> If you're a service provider, don't buy a consumer product and hope to
> sell it on at a similar (or higher) SLA rate to other consumers; that
> way lies ruin.

I don't know of "Consumers" that buy l2vpn's. Most consumers usually go
for ADSL, FTTH or 4G... all carrying IP :-).

We have several customers that buy EoMPLS circuits from us both within
and outside of countries, and between continents. The reasons vary, but
safe to say they've been happy.

Of course, should the requirements get to 10Gbps or more, moving them
over to DWDM makes plenty of commercial sense. In my experience, trying
to provide EoMPLS transport to customers in the 6Gbps region and above,
when your backbone consists mostly of N x 10Gbps links, is just asking
for it. I'd recommend considering doing that only if one had N x 100Gbps
everywhere, including router-switch 802.1Q trunks.

Mark.

Re: BFD for long haul circuit

[Nick Hilliard]

Tom Hill wrote on 17/07/2020 16:06:

If you're a service provider, don't buy a consumer product and hope to
sell it on at a similar (or higher) SLA rate to other consumers; that
way lies ruin.


I was going to suggest that there wasn't much in the way of consumer 
grade international circuits, so why would you even bring this up?  But 
then I lol'd.


Nick

Re: BFD for long haul circuit

[Tom Hill]

On 17/07/2020 10:57, Mark Tinka wrote:
> I suppose a lot of customers go for it because they need an Ethernet
> service slower than 1Gbps, and 1Gbps via a DWDM service is pricier.
> 
> Where I've seen it be popular is in intercontinental circuits that
> customers want in order to test a market with as little exposure as
> possible.


The differentiation is: consumer vs. service provider.

If you're a service provider, don't buy a consumer product and hope to
sell it on at a similar (or higher) SLA rate to other consumers; that
way lies ruin.

-- 
Tom

Re: BFD for long haul circuit

[Mark Tinka]

On 17/Jul/20 11:50, Robert Raszuk wrote:
>
> Fortunately  very fortunately Mark.

Hehe, I meant in the context of not having a similar condition as the OP.


> L2VPNs running on someone's IP backbone sold by many as "circuits" has
> many issues ... stability, MTU blackhols, random drops - and that is
> pretty much the same all over the world :( 
>
> Very unfortunate technology just to mux more users and get more $$$
> from single investment.

Can't argue with you.

I suppose a lot of customers go for it because they need an Ethernet
service slower than 1Gbps, and 1Gbps via a DWDM service is pricier.

Where I've seen it be popular is in intercontinental circuits that
customers want in order to test a market with as little exposure as
possible.

Mark.

Re: BFD for long haul circuit

[Robert Raszuk]

>  Unfortunately not.

Fortunately  very fortunately Mark.

L2VPNs running on someone's IP backbone sold by many as "circuits" has many
issues ... stability, MTU blackhols, random drops - and that is pretty much
the same all over the world :(

Very unfortunate technology just to mux more users and get more $$$ from
single investment.

Cheers,
R.

On Fri, Jul 17, 2020 at 8:43 AM Mark Tinka  wrote:

>
>
> On 17/Jul/20 02:37, Harivishnu Abhilash wrote:
>
>
>
> Thanks for the update. You have any backhauls, that is running over an L2
> xconnect  ? I’m facing issue only on the backhaul link over a l2vpn ckt.
>
>
> Unfortunately not. All our backbones are either over dark fibre or EoDWDM.
>
> Mark.
>

Re: BFD for long haul circuit

[Mark Tinka]

On 17/Jul/20 02:37, Harivishnu Abhilash wrote:

>  
>
> Thanks for the update. You have any backhauls, that is running over an
> L2 xconnect  ? I’m facing issue only on the backhaul link over a l2vpn
> ckt. 
>

Unfortunately not. All our backbones are either over dark fibre or EoDWDM.

Mark.