Skip to Content.
Sympa Menu

ntacpeering - Re: Apple Prefix not on I2PX

Subject: NTAC Peering Working Group

List archive

Re: Apple Prefix not on I2PX


Chronological Thread 
  • From: David Farmer <>
  • To: Michael H Lambert <>
  • Cc: "" <>
  • Subject: Re: Apple Prefix not on I2PX
  • Date: Fri, 27 Aug 2021 07:51:34 -0500
  • Dkim-filter: OpenDKIM Filter v2.11.0 mta-p6.oit.umn.edu 4Gx03D5mbSz9vDvt
  • Dmarc-filter: OpenDMARC Filter v1.3.2 mta-p6.oit.umn.edu 4Gx03D5mbSz9vDvt

The prefixes in 17.253.0.0/16 are part of Apple's regionalized CDN; the /24s within it are only announced to peers at a particular peering point.  I refer you back to an email that Jeff sent back in 2015, seen below;

On Fri, Aug 27, 2021 at 06:59 Michael H Lambert <> wrote:
I don’t know whether or not the Internet2 folks have a sufficient in with Apple on I2PX peering, but we’re seeing the prefix 17.253.120.0/24 over commodity but not I2PX. I don’t think it’s unique in that regard, but having that traffic take a path from Apple over I2PX would be helpful from the standpoint of a member’s commodity policers.

Michael


On Wed, Nov 18, 2015 at 18:15 Jeff Bartig <> wrote:

Peering & Routing WG Members,

I've been working with Apple since the iOS9 release on issues
relating to where their geolocation algorithm is directing users
to download software updates.  Many R&E networks were seeing Apple
direct their users to Apple download servers that were only available
via their paid transit and not via TR/CPS or even local peering the
R&E might have with Apple.

Apple has made some additional changes in the last 24 hours to their
geolocation mapping.  They are requesting that R&E networks test
this and report any issues.  I've created a spreadsheet where I've
been having various R&E networks record the results of DNS queries:

https://docs.google.com/spreadsheets/d/1V5cBpmwlWRf0eq4kvl0ctcMDMklyAAB8e8gxTMexQY0/edit?usp=sharing

If you have a few minutes and could contribute some data, I would
appreciate it.  I'm basically asking for you to look up the DNS A
record for "appldnld.apple.com" and then look up the PTR record for
one of the returned addresses.  Both the A and PTR results can be
appended to the above spreadsheet along with time and location
details.

Apple has pointed out some other issues that may be impacting R&E
networks receiving Apple traffic via TR/CPS or their own local
peering with Apple:

1.  AS Path Prepending:  in some cases, Apple is seeing the same
length AS path to a campus via both TR/CPS and a network the campus
buys transit from.  If this network is one that settlement-free
peers with Apple, Apple will treat it the same as TR/CPS and may
choose that path over TR/CPS.  I think a common example of this may
be Hurricane Electric paid transit.  Prepending towards paid transit
can encourage traffic to route via TR/CPS, rather than via paid
transit.

2.  Apple is using an end user's DNS resolver IP (recursive DNS
server) for Geolocation and determining the best path for routing
to the user.  If the IP network of the DNS server and the IP network
of the end user are advertised differently via BGP, Apple may pick
a poor path to the end user.

3.  Apple has now established dual routers and server clusters in
each major city where they peer.  These routers/servers apparently
are not interconnected.  If you are directed to one cluster, but
peer with the other, the traffic from Apple may end up taking transit
to reach the end user, even though there is local peering.  Internet2
TR/CPS is working on establishing peering with both clusters in
every city where we privately interconnect with Apple to address
this issue.

Thanks for your help,

Jeff

--
Jeff Bartig
University of Wisconsin

(608) 262-8336



Archive powered by MHonArc 2.6.24.

Top of Page