There are actually quite a few commands, and it depends on a lot of factors.
- What is the source interface for the traffic?
- Are we going to use IPv4 or IPv6 transport
- Are we registering with cisco.com, through a proxy, or with a satellite server on-premise
- Do we intend to do a DNS lookup for the hostname of the server or a static IP address configuration (or even static DNS)
- For HTTS and cisco.com, do we have the quovadis certificate and when we communicate to get the CRL from server for HTTPS can we access that site
Source Interface
This tells call-home and smart licensing the IP address to source the traffic from.
call-home
service active
contact smart-licensing
source-interface MgmtEth0/RP0/CPU0/0
profile CiscoTAC-1
In additional to setting source-interface if a VRF is used then we need to add vrf config.
call-home
vrf MGMT
service active
contact smart-licensing
source-interface MgmtEth0/RP0/CPU0/0
profile CiscoTAC-1
Also this command if using a VRF.
http client vrf MGMT
IPv4 or IPv6
If you have both IPv4 and IPv6 on an interface then IPv6 will be preferred. debug ip http client all will show the IP address being used.
Example of a request using IPv6 for the correct hostname.
RP/0/RSP1/CPU0:Sep 25 14:55:42.000 PERU: http_client[243]: httpc_check_ip_address_type: Host:tools.cisco.com
RP/0/RSP1/CPU0:Sep 25 14:55:42.001 PERU: http_client[243]: IPv6 address: <omitted> (tools.cisco.com)
RP/0/RSP1/CPU0:Sep 25 14:55:42.001 PERU: http_client[243]: we are using <omitted>::a finally
DNS Lookup or Static IP Assignment
Below examples will show how to setup DNS in a few ways, first how to statically resolve a hostname to an IP address using the ipv[4|6] host tools.cisco.com <address> command, and then by setting up DNS for resolution. Another option that sometimes works is replacing the tools.cisco.com part of the URL in call-home with the IP address.
Make sure to use a VRF if needed.
IPv4
domain ipv4 host cisco.com 72.163.4.161
domain name cisco.com <<<<not recommended, recommended to keep it the same domain as customer domain
domain name-server <omitted>
domain lookup source-interface MgmtEth0/RP0/CPU0/0
So in the above we can either use the host config to setup a static DNS entry for the host or setup a name-server and lookup source-interface to do the DNS lookup like normal.
IPv6
Below is a example where we setup a name-server in a VRF, specify a lookup interface (preferably the same as call-home setting), and as we can see we actually set a static assignment in the first config line for tools.cisco.com.
domain ipv6 host tools.cisco.com 2001:420:1201:5::a
domain name cisco.com
domain name-server <omitted>
domain lookup source-interface Loopback999
basically the same as ipv4.
Example to choose IPv4 over IPv6
http client source-interface ipv4 MgmtEth0/RP0/CPU0/0
Quovadis Certificate
RP/0/RSP0/CPU0:router#show crypto ca certificates
Fri Dec 13 05:33:23.984 UTC
Trustpoint : cisco
==================================================
CA certificate
Serial Number : 05:09
Subject:
CN=QuoVadis Root CA 2,O=QuoVadis Limited,C=BM
Issued By :
CN=QuoVadis Root CA 2,O=QuoVadis Limited,C=BM
Validity Start : 18:27:00 UTC Fri Nov 24 2006
Validity End : 18:23:33 UTC Mon Nov 24 2031
SHA1 Fingerprint:
CA3AFBCF1240364B44B216208880483919937CF7
Without this certificate SSL to cisco.com will fail.
CRL optional is an optional config item that comes into play when we are unable to download the CRL list
RP/0/RSP0/CPU0:Mar 16 18:19:42.199 EDT: call_home[289]: CALL-HOME-TRACE: http resp from https://tools.cisco.com/its/service/oddce/services/DDCEService failed, tid (47), response status (324), err string (HTTPS error)
RP/0/RSP0/CPU0:Mar 16 18:19:42.199 EDT: call_home[289]: CALL-HOME-TRACE: Send HTTP msg to url " https://tools.cisco.com/its/service/oddce/services/DDCEService"; failed, rc 324, error string "HTTPS error"
RP/0/RSP0/CPU0:Mar 16 18:19:42.199 EDT: call_home[289]: CALL-HOME-TRACE: Failed to send request to all URLs
You may also see logs like these from debug:
RP/0/RP0/CPU0:Nov 1 10:23:59.109 JST: http_client[150]: Failed to retrieve CRL from http://gateway.zscloud.net/zscaler-zscrl--4.crl.
RP/0/RP0/CPU0:Nov 1 10:23:59.109 JST: http_client[150]: pki_c3m_get_crl_remote_from_cert: Failed to retrieve CRL from http://gateway.zscloud.net/zscaler-zscrl--4.crl.
RP/0/RP0/CPU0:Nov 1 10:23:59.109 JST: http_client[150]: pki_c3m_add_cert_issuer_crl_store: Cannot find CRL from the issuer
RP/0/RP0/CPU0:Nov 1 10:23:59.109 JST: http_client[150]: Error in adding trusted Cert/Fetching CRL
RP/0/RP0/CPU0:Nov 1 10:23:59.109 JST: http_client[150]: The issuer_cert and the crl_obj count is 1
RP/0/RP0/CPU0:Nov 1 10:23:59.109 JST: http_client[150]: Error in fetching the issuer cert and CRL.
As per above we have an HTTP response but an HTTPS error, this could be a number of things but more than likely its due to the CRL not being downloaded.To verify that we have connectivity to tools.cisco.com we need to check a few things in next section and try with crl optional set.
crypto ca trustpoint Trustpool
vrf Mgmt <<< necessary if our request goes out a VRF
crl optional
Verifying connectivity to tools.cisco.com
A few ways to rule out connectivity such as DNS issues include pinging the IP address, pinging the hostname, and finally telnetting to the IP or hostname on ports 80 or 443
RP/0/RSP0/CPU0:ASR-9010-D#telnet tools.cisco.com 80
Name resolution failed (tools.cisco.com): host nor service provided, or not known
RP/0/RSP0/CPU0:ASR-9010-D#telnet tools.cisco.com 443
Name resolution failed (tools.cisco.com): host nor service provided, or not known
RP/0/RSP0/CPU0:ASR-9010-D#
In the above outputs we see that DNS failed, we should get an open socket on those ports and a '>' prompt, simply exit once you get the prompt and that will verify connectivity. Both ports 80 and 443 must be open.
Finally remember if you are using a VRF and a command has a VRF option then use it.
Sam
