IOS new versions and network load

Mon Sep 18 03:05:05 UTC 2017

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.  

https://www.peeringdb.com/net/3554

Sent from my iPhone
> On Sep 17, 2017, at 21:50, Mel Beckman <mel at beckman.org> wrote:
> 
> It is still there. MacMiniColo.
> 
> -mel beckman
> 
>> On Sep 17, 2017, at 7:48 PM, Mel Beckman <mel at beckman.org> wrote:
>> 
>> There used to be a Mac mini "hotel" at Switch networks in Vegas. I think it's still there.
>> 
>> -mel 
>> 
>>>> On Sep 17, 2017, at 4:44 PM, Jean-Francois Mezei <jfmezei_nanog at vaxination.ca> wrote:
>>>> 
>>>> On 2017-09-17 19:37, Eduardo Schoedler wrote:
>>>> 
>>>> Server is an app now, any MacOS can have it running.
>>> 
>>> But do carriers/ISPs really want to deal with a rack unfriendly Mac Mini
>>> or iMac at a carrier hotel?  If the Server App could run on Linux, or if
>>> OS-X could boot on standard servers, perhaps, it it seems to be a very
>>> bad fit in carrier/enterprise environments.
>>> 
>>>> Implementation will be a little tricky, because you need your
>>>> customers to look a record in your domain.
>>> 
>>> 
>>> I've tried reading some about it.
>>> The cache server app registers with Apple its existence and the IP
>>> address ranges it serves
>>> 
>>> When a client wants to download new IOS version, Apple checked and finds
>>> that the client's IP is served by the caching server whose "local" IP is
>>> a.b.c.d (akaL the inside NAT IP address). Tells client to get version of
>>> software from that IP address.
>>> 
>>> The DNS TXT records are used by the Caching Server to get the list of IP
>>> blocks it can serve.  (not needed in the target small office
>>> environments where everyone is on same subnet and the caching server can
>>> tell the apple serves the one subnet it seves).
>>> 