Image: iStock/BartekSzewczyk
The content cache service baked into more recent versions of macOS is beneficial for organizations of all types and sizes to get the latest Apple updates, apps, and iCloud data to all the devices behind the company’s firewall. In the case of iCloud documents, it can get users working productively a lot more quickly, as shared documents are updated in real time and made available to all who need them.
SEE: Future of 5G: Projections, rollouts, use cases, and more (free PDF) (TechRepublic
As someone who has managed large Apple-based infrastructures, I can attest to the boost in network performance, reduction in use of bandwidth, and timely updates that are provided to all devices across the network. One of the best parts about using the content cache service is that in most cases little to no additional configuration is required: The default setup works beautifully and immediately.
Since all networks are not created equal, sometimes with more specialized network configurations the content cache server will require tweaking to allow it to communicate with all segments of the network or to properly pass traffic, such as those using network address translation (NAT) to restrict or protect WAN traffic going out to the internet. Using the two examples below, admins can work with their network teams to ensure cache servers are communicating properly on customized networks.
1. Networks using multiple IP ranges/scopes
While the default configuration of the content cache service is meant to handle traffic on the same local network subnet that the cache server is on, the service is capable of routing data to other networks using more robust options, such as that coming from different IP address ranges. By selecting to cache content for devices using custom local networks, under Settings > Sharing > Content Cache > Advanced Settings, admins can configure IP addresses that will have cached content served to them. This is necessary when a server will be serving data across multiple IP ranges.
SEE: How to use advanced configurations of Apple’s content cache service (TechRepublic)
When selecting to cache content for devices using custom local networks with fallback, the same settings as above will apply. However, if each network segment already has a cache server configured, the clients will look to the server that sits on their unique segments for cached data. If none are found, then it will jump to the server configured to listen on multiple subnets for cached data. This helps to build redundancy in case of failure while balancing the load across multiple cache servers.
2. NAT or double NAT-enabled networks
Networks with address translation add an extra layer of protection to communications by effectively keeping the private range (LAN) separate from the public range (WAN). Apple’s content cache services do an admirable job of communicating through the LAN and registering the server frequently with Apple’s servers to determine the WAN address. However, this might not work as intended, depending on the configuration of your organization’s network. In some cases, it may be required to include the public IP addresses that the cache server will route data through within the configuration of the content cache itself by entering them manually via Settings > Sharing > Content Cache > Advanced Settings. These settings can be granular, noting only single IP addresses or may encompass entire IP ranges, as necessary.
Within the same setting window, the DNS Configuration button allows admins to enter the TXT record information that matches the entry within their DNS server(s) so that the cache server can communicate with clients on disparate networks, but also allow clients to resolve lookups to the cache server via DNS, as they’ll likely be on entirely different subnets, again depending on your organization’s network configuration.
