Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'
Finally figured this out!  

We reference many of our very active SQL Servers and Instances with SQL aliases and canonical names.  This allows us to perform parallel upgrades and switch machines in and out without code interruption.  The SQL aliases are all configured to reference the canonical names for the same reason.  The standard SPNs we had registered are for the machine names.

EXAMPLE
SQL Server SSxyz\xyzInstance listening on port 12345 has registered SPNs:


MSSQLSVC/SSxyz.mydomain.com:12345
MSSQLSVC/SSxyz:12345
MSSQLSVC/SSxyz:xyzInstance


These are all registered to the service account that owns MSSQLSVC on that machine and delegation is set for each to pass credentials.

The server and instance also have canonical name cxyz\xyzInstance.  Finally, the SQL Server has a 32bit and 64bit alias of xyzAlias, pointing to canonical name cxyz\xyzInstance.

During a double hop scenario from my local pc to xyzAlias to abcAlias, Kerberos authentication fails and falls back to NTLM because the alias and SPN cannot be resolved.  This is why the logs were showing NTLM.

The fix was to add a few more SPNs to register the canonical name of the server to the actual name.  Then the SQL service is registered with another SPN. like this:


setspn -s host/cxyz SSxyz
setspn -s host/cxyz.mydomain.com SSxyz
setspn -s MSSQLSVC/cxyz:12345 sqlserviceaccountname 
setspn -s MSSQLSVC/cxyz:xyzInstance sqlserviceaccountname 


Once registered, each SPN is configured for delegation.
These appear as unique SPNs and allow the SQL alias to resolve to the actual machine name. The double hop authentication logged is kerberos and everyone is happy!  Except the AD guys...they're going to have a lot of SPNs to register in a couple of hours.