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 <m...@beckman.org> wrote: > > It is still there. MacMiniColo. > > -mel beckman > >> On Sep 17, 2017, at 7:48 PM, Mel Beckman <m...@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_na...@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). >>>