Re: USA local SIM card

On 2017-09-18 19:01, Nathan Anderson wrote: > The larger issue for you with T-Mobile might be their previous (and ongoing?) > use of AWS bands (split 1700MHz uplink/2100 downlink) for 3G service, which > very few phones sold outside of the U.S. support. They have been working > nationwide to

Re: USA local SIM card

On 09/17/17 14:07, Max Tulyev wrote: I'm going to visit USA for two weeks. I want to buy a local prepaid SIM card mostly for IP access. I use these guys when I fly through the US. Can't say who the carrier(s) they might use. Can't say if there was a non-natted address. But I think IPv6

RE: USA local SIM card

I cannot think of any prepaid plans in the U.S. that meet all of your requirements, though I am far from being familiar with all of them. Here is what I (think I) "know", though I would love to be set straight on anything I got wrong or missed: Generally 3G is available wherever LTE is.

Re: 100G QSFP28 DAC cables - experience

On 9/6/17 00:17, Jiri Prochazka wrote: > Hi folks, > > I'm wondering if anyone have (either positive or negative) experience > with 100G QSFP28 DAC cables? I found the ones we tested to be substantially more finicky particularly at 5 meter then 10gig dacs, adding 4 x 25 sfp28 breakout on the other

Re: IPv6 migration steps for mid-scale isp

Fully agree, 464XLAT is the way to go. We have tested this in many IPv6-only access deployments, non-cellular networks (cellular is well tested by T-Mobile and others, that have got it in production for years). We always have the issue of the CPEs support, but this is the same problem if you

Re: IOS new versions and network load

They also say the domain needs to be in your domain search field on your end user device, meaning I think the enduser device looks up whatever default hostname, appending whatever domain name is in your client. Your authoritative DNS then returns the IP of your Apple cache. - Mike

Re: IOS new versions and network load

On 2017-09-18 08:48, Mike Hammett wrote: > It looks very difficult to manage, given the DNS TXT records and domain > search fields. If it was as simple as entering the supported IP ranges, it'd > be a lot easier to implement. I would have to read the stuff again, but my understanding is:

Re: IOS new versions and network load

> On Sep 18, 2017, at 12:14 PM, valdis.kletni...@vt.edu wrote: > > On Mon, 18 Sep 2017 16:57:55 +0100, Marco Slater said: >>> While we don’t use Apple's caching servers we do have transparent caching >>> in place which nets us about 82% of their content being serverd locally. On >>> a >>> big

Re: IOS new versions and network load

> On Sep 18, 2017, at 11:57 AM, Marco Slater wrote: > >> While we don’t use Apple's caching servers we do have transparent caching in >> place which nets us about 82% of their content being serverd locally. On a >> big IOS update it will probably be close to 99% for

Re: IOS new versions and network load

On Mon, 18 Sep 2017 16:57:55 +0100, Marco Slater said: > > While we don’t use Apple's caching servers we do have transparent caching > > in place which nets us about 82% of their content being serverd locally. On > > a > > big IOS update it will probably be close to 99% for that one title. >

RE: IOS new versions and network load

> While we don’t use Apple's caching servers we do have transparent caching in > place which nets us about 82% of their content being serverd locally. On a > big IOS update it will probably be close to 99% for that one title. Would you be open to elaborating a bit on how that’s set up on your

Re: IOS new versions and network load

On 9/17/17 20:05, JASON BOTHE wrote: My best experience with Apple has been directly peering with them. Definitely handles the update issue without putting strain on transit links. Apple is very well connected. The cache thing mentioned in their peeringdb entry appears useless outside of

RE: IOS new versions and network load

While we don’t use Apple's caching servers we do have transparent caching in place which nets us about 82% of their content being serverd locally. On a big IOS update it will probably be close to 99% for that one title. Luke Guillory Vice President – Technology and Innovation Tel:

Re: IOS new versions and network load

*nods* It appears to be very enterprise focused, but then it's mentioned on their PeeringDB page, so that makes one wonder. It doesn't seem like it would be easy for an ISP to manage given that they can't set the required domain search field via static or PPPoE. That would leave DHCP as the

Re: IOS new versions and network load

Curious as mentioned if anyone doing this on scale? I kind of doubt it but love to hear otherwise. My assumption is this is more Enterprise focused than ISP Paul Sent from my iPhone > On Sep 18, 2017, at 8:48 AM, Mike Hammett wrote: > > We've been looking into the

Re: IOS new versions and network load

We've been looking into the caching server bit lately given that we're not due to get an official Apple node for at least another year yet. It looks very difficult to manage, given the DNS TXT records and domain search fields. If it was as simple as entering the supported IP ranges, it'd be a

Re: IOS new versions and network load

On Mon, Sep 18, 2017 at 12:48:45AM -0400, Christopher Morrow wrote: > On Sun, Sep 17, 2017 at 11:05 PM, JASON BOTHE wrote: > > My best experience with Apple has been directly peering with them. > > Definitely handles the update issue without putting strain on transit > > links.

Re: IOS new versions and network load

Thank you Jason! Big week ahead for http://as714.peeringdb.com Cheers! -ren.pr...@gmail.com > On Sep 18, 2017, at 5:48 AM, Christopher Morrow > wrote: > >> On Sun, Sep 17, 2017 at 11:05 PM, JASON BOTHE wrote: >> >> My best experience with Apple has

Hurricane Maria: U.S. Virgin Islands suspends recovery efforts

U.S. Virigin Islands suspended hurricane recovery efforts on the islands in order to prepare for potential landfall by Hurricane Maria on Tuesday night/Wednesday morning. Hurricane Maria is expected to strengthen to a major hurricane by Monday evening. Storm preparation efforts on the U.S.