Thank you Jason! Big week ahead for http://as714.peeringdb.com Cheers! -ren.provo@gmail.com
On Sep 18, 2017, at 5:48 AM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Sun, Sep 17, 2017 at 11:05 PM, JASON BOTHE <jbothe@me.com> 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.
apple is AS714 though, right? or are they having the trucking company do their delivery of bits?
On Sep 17, 2017, at 21:50, Mel Beckman <mel@beckman.org> wrote:
It is still there. MacMiniColo.
-mel beckman
On Sep 17, 2017, at 7:48 PM, Mel Beckman <mel@beckman.org> wrote:
There used to be a Mac mini "hotel" at Switch networks in Vegas. I
Sent from my iPhone think it's still there.
-mel
On Sep 17, 2017, at 4:44 PM, Jean-Francois Mezei <
jfmezei_nanog@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).