ASR9K SSL communication error with Smart License Satellite Enhanced server

panayiotiscy · ‎01-16-2019

Hello All,

We have deployed the Satellite Enhanced edition 6.1.0 in our environment we are in the process of registering a few ASR boxes to it. It seems that there is problem when the the HTTPS is used, resulting in registration failure while for the HTTP the same box can register successfully.

We have ended up with the below messages that we try to figure out and resolve:

Jan 16 10:23:18.956 call_home/error 0/RSP0/CPU0 t8 call_home_http_resp_data(), httpc response error, Error during SSL communication

and

RP/0/RSP0/CPU0:Jan 16 10:30:29.181 EET: call_home[156]: CALL-HOME-TRACE: call_home_wait_for_httpc_resp : unblocked wait for tid (60), status is (324)err string is (HTTPS error)
RP/0/RSP0/CPU0:Jan 16 10:30:29.181 EET: call_home[156]: CALL-HOME-TRACE: call_home_remove_httpc_resp_node() is entered
RP/0/RSP0/CPU0:Jan 16 10:30:29.181 EET: call_home[156]: CALL-HOME-DETAIL: UNLOCKING MUTEX 7
RP/0/RSP0/CPU0:Jan 16 10:30:29.181 EET: call_home[156]: CALL-HOME-TRACE: http resp from https://x.x.x.x/Transportgateway/services/DeviceRequestHandler failed, tid (60), response status (324), err string (HTTPS error)
RP/0/RSP0/CPU0:Jan 16 10:30:29.181 EET: call_home[156]: CALL-HOME-TRACE: Send HTTP msg to url "https://x.x.x.x/Transportgateway/services/DeviceRequestHandler" failed, rc 324, error string "HTTPS error"
RP/0/RSP0/CPU0:Jan 16 10:30:29.181 EET: call_home[156]: CALL-HOME-TRACE: Failed to send request to all URLs
RP/0/RSP0/CPU0:Jan 16 10:30:29.181 EET: call_home[156]: CALL-HOME-TRACE: lock client mutex
RP/0/RSP0/CPU0:Jan 16 10:30:29.181 EET: call_home[156]: CALL-HOME-TRACE: client stats entry with subtype REGISTRATION found
RP/0/RSP0/CPU0:Jan 16 10:30:29.181 EET: call_home[156]: CALL-HOME-TRACE: call_home_smart_license_stats_chkpt_add() is entered
RP/0/RSP0/CPU0:Jan 16 10:30:29.182 EET: call_home[156]: CALL-HOME-DETAIL: call_home_smart_license_stats_chkpt_add: save chkpt for smart license stat successful
RP/0/RSP0/CPU0:Jan 16 10:30:29.182 EET: call_home[156]: CALL-HOME-TRACE: unlock client mutex

Did any experience this before?

Thanks

smilstea · ‎01-17-2019

There are a number of things this could be.

First one is that there is no communication to sd.symcb.com and you can verify that with a ping and traceroute to sd.symcb.com

If there is no communication then there are 2 options:

1. Fix the communication issue (analyze what is blocking the traffic to that server)

2. Ignore this via configuration:

config

crypto ca trustpoint Trustpool

crl optional

commit

(you may need to do the crl optional even if communication to the server works, IE ping).

That command allows certificates of other peers to be accepted without downloading the CRL from a certificate authority and not mark it as revoked.
It is explained in detail are here:

 https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r6-1/security/command/reference/b-syssec-cr-asr9k-61x/b-syssec-cr-asr9k-61x_chapter_01000.html#wp2972289201

This happens when the router doesn't have the appropriate CRL from the peer in its memory so it tries to download it from a Certificate Authority but it failed.

The second possibility is that the license was not properly registered, in which case you can force it:

license smart register idtoken <id-token> force