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).
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@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).
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 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).
MacMiniColo is now part of MacStadium, we have tons of Mac Minis and Mac Pros in Las Vegas NV, Atlanta GA and Dublin Ireland. We are currently moving out of SWITCH's NAP2 and into zColo Las Vegas. Our speciality it private clouds on the Mac platform for CI/CD environments. 360 degrees views cole aisle: https://kuula.co/post/7lkFV mini racks: https://kuula.co/post/7lkXV On Sep 17, 2017, at 7:53 PM, Mel Beckman <mel@beckman.org<mailto:mel@beckman.org>> wrote: It is still there. MacMiniColo. -mel beckman On Sep 17, 2017, at 7:48 PM, Mel Beckman <mel@beckman.org<mailto:mel@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@vaxination.ca<mailto: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).
On 9/17/17 20:02, Robert Perkins wrote:
mini racks:https://kuula.co/post/7lkXV
Even if you're not doing Minis at that scale they easily fit into a 1U space. Someone said minis aren't rack friendly and no, they aren't rackmount standalone, but just add a 1U shelf. ~Seth
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@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 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).
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).
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).
On Mon, Sep 18, 2017 at 12:48:45AM -0400, Christopher Morrow 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?
You may be shuffling the opaque peeringdb 'net_id' that is assigned to each network with the ASN of such a network. These entry points lead to the same information: https://www.peeringdb.com/asn/714 https://as714.peeringdb.com/ https://www.peeringdb.com/net/3554 Kind regards, Job
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 an enterprise environment where a DNS search domain can be forced. Ideally the cache should be able to speak BGP and learn prefixes that way, especially if Apple can't or won't peer in a region. ~Seth
My understanding was that macminicolo stopped accepting new customers in Switch after they got bought out?
On Sep 17, 2017, at 19: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 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).
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 lot easier to implement. The caching service does support a lot more than content than "once a year" https://support.apple.com/en-us/HT204675 ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Jean-Francois Mezei" <jfmezei_nanog@vaxination.ca> To: "Eduardo Schoedler" <listas@esds.com.br> Cc: Nanog@nanog.org Sent: Sunday, September 17, 2017 6:43:50 PM Subject: Re: IOS new versions and network load 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).
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 <nanog@ics-il.net> wrote:
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 lot easier to implement.
The caching service does support a lot more than content than "once a year" https://support.apple.com/en-us/HT204675
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
----- Original Message -----
From: "Jean-Francois Mezei" <jfmezei_nanog@vaxination.ca> To: "Eduardo Schoedler" <listas@esds.com.br> Cc: Nanog@nanog.org Sent: Sunday, September 17, 2017 6:43:50 PM Subject: Re: IOS new versions and network load
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).
*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 only way to assign that field and then that's assuming that whatever router is at the customer location passes that field through to the end user devices. It seems like it would be a lot more effective to ditch the requirement for the domain search field and just let the caching server tell Apple what prefixes it supports and there be an automated verification system using RIR records that the request is legitimate. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Paul Stewart" <paul@paulstewart.org> To: "Mike Hammett" <nanog@ics-il.net> Cc: Nanog@nanog.org Sent: Monday, September 18, 2017 7:53:00 AM Subject: 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 <nanog@ics-il.net> wrote:
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 lot easier to implement.
The caching service does support a lot more than content than "once a year" https://support.apple.com/en-us/HT204675
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
----- Original Message -----
From: "Jean-Francois Mezei" <jfmezei_nanog@vaxination.ca> To: "Eduardo Schoedler" <listas@esds.com.br> Cc: Nanog@nanog.org Sent: Sunday, September 17, 2017 6:43:50 PM Subject: Re: IOS new versions and network load
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).
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: 985.536.1212 Fax: 985.536.0300 Email: lguillory@reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . -----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Paul Stewart Sent: Monday, September 18, 2017 7:53 AM To: Mike Hammett Cc: Nanog@nanog.org Subject: 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 <nanog@ics-il.net> wrote:
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 lot easier to implement.
The caching service does support a lot more than content than "once a year" https://support.apple.com/en-us/HT204675
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
----- Original Message -----
From: "Jean-Francois Mezei" <jfmezei_nanog@vaxination.ca> To: "Eduardo Schoedler" <listas@esds.com.br> Cc: Nanog@nanog.org Sent: Sunday, September 17, 2017 6:43:50 PM Subject: Re: IOS new versions and network load
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).
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 network? :) Regards, Marco Slater On 18 Sep 2017, 14:55 +0100, Luke Guillory <lguillory@reservetele.com>, 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 that one title.
Luke Guillory Vice President – Technology and Innovation
Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory@reservetele.com
Reserve Telecommunications 100 RTC Dr Reserve, LA 70084
_________________________________________________________________________________________________
Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. .
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Paul Stewart Sent: Monday, September 18, 2017 7:53 AM To: Mike Hammett Cc: Nanog@nanog.org Subject: 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 <nanog@ics-il.net> wrote:
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 lot easier to implement.
The caching service does support a lot more than content than "once a year" https://support.apple.com/en-us/HT204675
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
----- Original Message -----
From: "Jean-Francois Mezei" <jfmezei_nanog@vaxination.ca To: "Eduardo Schoedler" <listas@esds.com.br Cc: Nanog@nanog.org Sent: Sunday, September 17, 2017 6:43:50 PM Subject: Re: IOS new versions and network load
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).
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.
Would you be open to elaborating a bit on how that’s set up on your network? :)
I'm particularly interested in how they introspect https:// targets. Apple *IS* using https:// (or other TLS-secured connections), right?
On Sep 18, 2017, at 12:14 PM, valdis.kletnieks@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 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 network? :)
I'm particularly interested in how they introspect https:// targets. Apple *IS* using https:// (or other TLS-secured connections), right?
I see no https in the XML right now. Only these hostnames are referenced: appldnld.apple.com appldnld.apple.com.edgesuite.net apsu.apple.com - Jared
We use a commercial product from https://qwilt.com/. Here is some info for the month of August, while it does reduce transit the customers are also getting better speeds when it comes from us. We span links from our core to the server in order to get visibility into the server, this does cause some issues since we’ve expanded our core outside of one location. [cid:image003.jpg@01D3306F.82F47BC0] [cid:image004.png@01D3306F.82F47BC0] Luke Guillory Vice President – Technology and Innovation [cid:image48b438.JPG@a3e7a3b5.4ea77b73] <http://www.rtconline.com> Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory@reservetele.com Web: www.rtconline.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. From: Marco Slater [mailto:marco@marcoslater.com] Sent: Monday, September 18, 2017 10:58 AM To: Paul Stewart; Mike Hammett; Luke Guillory Cc: Nanog@nanog.org Subject: 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 network? :) Regards, Marco Slater On 18 Sep 2017, 14:55 +0100, Luke Guillory <lguillory@reservetele.com<mailto:lguillory@reservetele.com>>, 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 that one title. Luke Guillory Vice President – Technology and Innovation Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory@reservetele.com<mailto:lguillory@reservetele.com> Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . -----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Paul Stewart Sent: Monday, September 18, 2017 7:53 AM To: Mike Hammett Cc: Nanog@nanog.org<mailto:Nanog@nanog.org> Subject: 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 <nanog@ics-il.net<mailto:nanog@ics-il.net>> wrote: 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 lot easier to implement. The caching service does support a lot more than content than "once a year" https://support.apple.com/en-us/HT204675 ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Jean-Francois Mezei" <jfmezei_nanog@vaxination.ca To: "Eduardo Schoedler" <listas@esds.com.br Cc: Nanog@nanog.org Sent: Sunday, September 17, 2017 6:43:50 PM Subject: Re: IOS new versions and network load 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).
On Sep 18, 2017, at 11:57 AM, Marco Slater <marco@marcoslater.com> 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 that one title.
Would you be open to elaborating a bit on how that’s set up on your network? :)
I used to run a transparent cache that redirected tcp/80 traffic to a squid instance that was configured to hold the objects for an extended period of time and ignore the do-not-cache type options sent from the CDNs. A quick search in your favorite AltaVista location returns URLs like this: https://lkrms.org/caching-ios-updates-on-a-squid-proxy-server/ - Jared
I'm pretty sure I've seen huge hits on my Akamai caches during IOS release nights. But this is news to me about Apple having caches. Are Apple caches like Akamai, Netflix, Google, etc? -Aaron
On Sep 19, 2017, at 10:58 PM, Aaron Gould <aaron1@gvtc.com> wrote:
I'm pretty sure I've seen huge hits on my Akamai caches during IOS release nights.
I remember seeing this years ago. What I saw yesterday from my own home was IPv6 traffic to the Apple CDN nodes in Chicago.
But this is news to me about Apple having caches. Are Apple caches like Akamai, Netflix, Google, etc?
If you are at an IX or have traffic volumes, I would check this: https://www.peeringdb.com/asn/714 - Jared
Apple seems to be quite behind on their node roll out. They were talking about our Indianapolis IX getting one this year, but now we're at least another year away from one. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Jared Mauch" <jared@puck.nether.net> To: "Aaron Gould" <aaron1@gvtc.com> Cc: "Marco Slater" <marco@marcoslater.com>, "Paul Stewart" <paul@paulstewart.org>, "Mike Hammett" <nanog@ics-il.net>, "Luke Guillory" <lguillory@reservetele.com>, Nanog@nanog.org Sent: Wednesday, September 20, 2017 5:41:24 AM Subject: Re: IOS new versions and network load
On Sep 19, 2017, at 10:58 PM, Aaron Gould <aaron1@gvtc.com> wrote:
I'm pretty sure I've seen huge hits on my Akamai caches during IOS release nights.
I remember seeing this years ago. What I saw yesterday from my own home was IPv6 traffic to the Apple CDN nodes in Chicago.
But this is news to me about Apple having caches. Are Apple caches like Akamai, Netflix, Google, etc?
If you are at an IX or have traffic volumes, I would check this: https://www.peeringdb.com/asn/714 - Jared
I've never quite understood CDNs and why more of them aren't more nimble. For most of them when we talk to them they're talking a full rack or more of deployment. Why haven't they all figured out how to do a single box or even a handful of boxes? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Mike Hammett" <nanog@ics-il.net> Cc: Nanog@nanog.org Sent: Wednesday, September 20, 2017 7:36:19 AM Subject: Re: IOS new versions and network load Apple seems to be quite behind on their node roll out. They were talking about our Indianapolis IX getting one this year, but now we're at least another year away from one. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Jared Mauch" <jared@puck.nether.net> To: "Aaron Gould" <aaron1@gvtc.com> Cc: "Marco Slater" <marco@marcoslater.com>, "Paul Stewart" <paul@paulstewart.org>, "Mike Hammett" <nanog@ics-il.net>, "Luke Guillory" <lguillory@reservetele.com>, Nanog@nanog.org Sent: Wednesday, September 20, 2017 5:41:24 AM Subject: Re: IOS new versions and network load
On Sep 19, 2017, at 10:58 PM, Aaron Gould <aaron1@gvtc.com> wrote:
I'm pretty sure I've seen huge hits on my Akamai caches during IOS release nights.
I remember seeing this years ago. What I saw yesterday from my own home was IPv6 traffic to the Apple CDN nodes in Chicago.
But this is news to me about Apple having caches. Are Apple caches like Akamai, Netflix, Google, etc?
If you are at an IX or have traffic volumes, I would check this: https://www.peeringdb.com/asn/714 - Jared
My Netflix servers are half a petabyte of cached movies and they are about 18 inches tall .... not sure what you mean. -Aaron Gould
A couple of the CDNs have one or multiple rack minimum deployments. You can get a Netflix box in 4U that does many TB of storage, BGP, etc. CDN in a box. A lot of them were just built with big scale in mind, based on the fact that the US has 10 or so major sites and the scale needed to serve that much of the US. Now it's all about getting to the edge, but they haven't made their deployment smaller to accommodate. Some parts of their businesses evolve very rapidly, while other parts of the same business plod along ridiculously slow. Not meaning to pick on Apple (or Microsoft who's in the same boat), but they're the original reason for this thread. Most of Apple or Microsoft's peak usage (major OS updates) could fit in a 10 year old desktop's RAM drive, provided the rest of the system could keep up with the throughput needs. I'm surprised more companies haven't more quickly adopted something the configuration of the Netflix box. It doesn't have to do everything, just do the high demand stuff well. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Aaron Gould" <aaron1@gvtc.com> To: "Mike Hammett" <nanog@ics-il.net> Cc: Nanog@nanog.org Sent: Wednesday, September 20, 2017 5:34:41 PM Subject: RE: IOS new versions and network load My Netflix servers are half a petabyte of cached movies and they are about 18 inches tall .... not sure what you mean. -Aaron Gould
On Wed, Sep 20, 2017 at 05:34:41PM -0500, Aaron Gould wrote:
My Netflix servers are half a petabyte of cached movies and they are about 18 inches tall .... not sure what you mean.
Serving different file types requires different things. If you are serving the same episodes from storage it's much different than live content, or serving dynamic updates based on entitlement levels, etc. Not all CDNs are like Netflix, for better or worse. - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
There are also considerations with the throughput capability of the hardware too. 500T in a couple RU is nice and all, but if the box can only push ~15Gbps because of bottlenecks in hardware, or the kernel isn't tuned, it's might be a lot less useful depending on the content, as Jared points out. On Thu, Sep 21, 2017 at 7:12 AM, Jared Mauch <jared@puck.nether.net> wrote:
On Wed, Sep 20, 2017 at 05:34:41PM -0500, Aaron Gould wrote:
My Netflix servers are half a petabyte of cached movies and they are about 18 inches tall .... not sure what you mean.
Serving different file types requires different things. If you are serving the same episodes from storage it's much different than live content, or serving dynamic updates based on entitlement levels, etc.
Not all CDNs are like Netflix, for better or worse.
- Jared
-- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Oh, thanks Jared, I don't know what Netflix puts in my caches that they have locally here on -site... can I know ? Will the OCA portal show my what types of things are in there ? -Aaron
https://help.apple.com/serverapp/mac/5.3/#/apd74DDE89F-08D2-4E0A-A5CD-155E34... https://support.apple.com/en-us/HT204675 They appear to be very enterprise focused. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Aaron Gould" <aaron1@gvtc.com> To: "Marco Slater" <marco@marcoslater.com>, "Paul Stewart" <paul@paulstewart.org>, "Mike Hammett" <nanog@ics-il.net>, "Luke Guillory" <lguillory@reservetele.com> Cc: Nanog@nanog.org Sent: Tuesday, September 19, 2017 9:58:02 PM Subject: RE: IOS new versions and network load I'm pretty sure I've seen huge hits on my Akamai caches during IOS release nights. But this is news to me about Apple having caches. Are Apple caches like Akamai, Netflix, Google, etc? -Aaron
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: caching server starts. caching server registers with Apple, gives it its local IP, as well as the IP ranges that it manages. When a client wants something, it first reaches out to an Apple server. That server decides which content server is nearest to the client, and if there is a caching server in the same network, will give the client the IP address to access that local caching server. (and this is where there is NAT friendliness , as other have pointed out, designed mostlty for enterprise). The business about TXT records is to allow real IPs with multiple ranges to be used. I *assume* that it is the caching server which reads those records upon startup and then transmits it to Apple when it "logs in" as a caching server. You can have up to 24 chained TXT records to list all the IP blocks you can service.
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 Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Jean-Francois Mezei" <jfmezei_nanog@vaxination.ca> To: nanog@nanog.org Sent: Monday, September 18, 2017 12:11:22 PM Subject: 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: caching server starts. caching server registers with Apple, gives it its local IP, as well as the IP ranges that it manages. When a client wants something, it first reaches out to an Apple server. That server decides which content server is nearest to the client, and if there is a caching server in the same network, will give the client the IP address to access that local caching server. (and this is where there is NAT friendliness , as other have pointed out, designed mostlty for enterprise). The business about TXT records is to allow real IPs with multiple ranges to be used. I *assume* that it is the caching server which reads those records upon startup and then transmits it to Apple when it "logs in" as a caching server. You can have up to 24 chained TXT records to list all the IP blocks you can service.
participants (18)
-
Aaron Gould -
Christopher Morrow -
Fake Name (hintss) -
Jared Mauch -
Jared Mauch
-
JASON BOTHE -
Jean-Francois Mezei -
Job Snijders -
Luke Guillory -
Marco Slater -
Mel Beckman -
Mike Hammett -
Paul Stewart -
Ren Provo -
Robert Perkins -
Seth Mattinen -
Tom Beecher -
valdis.kletnieks＠vt.edu