Problemen met bedrijfsdirectory " oplossen; host niet gevonden" problemen

Inleiding

In dit document wordt beschreven hoe u problemen met 'Host Not Found' kunt oplossen in de functie Corporate Directory van IP-telefoons.

Achtergrondinformatie

Belangrijke informatie die relevant is voor dit document is:

• De Corporate Directory is een door Cisco geleverde standaard IP-telefoonservice die automatisch wordt geïnstalleerd met Cisco Unified Communications Manager (CUCM).
• Informatie over telefoonabonnementen op de verschillende telefoondiensten wordt opgeslagen in de database in de telecasterservice, telecasterserviceparameter, telecastersubscribedparameter, telecastersubscribedservice tabellen.
• Wanneer u op de telefoon de optie Corporate Directory selecteert, verzendt de telefoon een HTTP- of HTTPS-verzoek naar een van de CUCM-servers en wordt deze als een XML-object geretourneerd als een HTTP(S)-reactie. Als HTTPS, dan is dit ook afhankelijk van de telefoon die verbinding maakt met TVS-service om het certificaat voor HTTPS te verifiëren. Op telefoons die midlets ondersteunen, kan dit worden geïmplementeerd in de midlet van de telefoon en worden beïnvloed door de instelling Services Provisioning.

Belangrijke informatie

• Verduidelijk of het probleem optreedt wanneer u toegang krijgt tot directory's of bedrijfsdirectory's.
• Wat is het veld Service UR dat is ingesteld onder de Corporate Directory-service?
  • Als de URL is ingesteld op Toepassing: Cisco/CorporateDirectory, dan maakt de telefoon op basis van de firmwareversie van de telefoon een HTTP- of HTTPS-verzoek.
  • Telefoons die firmwareversie 9.3.3 en hoger gebruiken, doen standaard een HTTPS-verzoek.
• Wanneer de service-URL is ingesteld op Application: Cisco/CorporateDirectory, stuurt de telefoon het HTTP(S)-verzoek naar de server die als eerste in de CallManager (CM) -groep staat.
• Identificeer de netwerktopologie tussen de telefoon en de server waarnaar het HTTP(S)-verzoek wordt verzonden.
• Besteed aandacht aan firewalls, WAN-optimizers, enzovoort in het pad dat HTTP(S)-verkeer kan laten vallen/belemmeren.
• Als HTTPS in gebruik is, moet u zorgen voor connectiviteit tussen de telefoon en de TVS-server en dat de TVS functioneert.

werkscenario

In dit scenario wordt de URL van de telefoonservice ingesteld op Application: Cisco/CorporateDirectory en gebruikt de telefoon HTTPS.

Dit voorbeeld toont het configuratiebestand van de telefoon met de juiste URL.

<phoneService  type="1" category="0">
<name>Corporate Directory</name>
<url>Application:Cisco/CorporateDirectory</url>
<vendor></vendor>
<version></version>
</phoneService>

Via de logboeken van de telefoonconsole kunt u deze stappen controleren.

1. De telefoon maakt gebruik van de HTTPS URL.

   7949 NOT 11:04:14.765155  CVM-appLaunchRequest: [thread=AWT-EventQueue-0]
   [class=cip.app.G4ApplicationManager] Creating application module -
    Corporate Directory
   7950 ERR 11:04:14.825312  CVM-XsiAppData::getCdUrl:
   [thread=appmgr MQThread]
   [class=xxx.xxx.xx] Using HTTPS URL

2. Het Tomcat-webcertificaat dat vanaf de directories-server aan de telefoon wordt aangeboden, is niet beschikbaar op de telefoon. Vandaar dat de telefoon probeert het certificaat te verifiëren via de Trust Verification Service (TVS).

   7989 ERR 11:04:15.038637  SECD: -HTTPS cert not in CTL, <10.106.111.100:8443>
   7990 NOT 11:04:15.038714  SECD: -TVS service available, can attempt via TVS

3. De telefoon kijkt eerst in de TVS-cache en als deze niet wordt gevonden, neemt deze contact op met de TVS-server.

   7995 NOT 11:04:15.039286  SECD: -TVS Certificate Authentication request
   7996 NOT 11:04:15.039394  SECD: -No matching entry found at cache

4. Aangezien de verbinding met de tv ook veilig is, wordt een certificaatverificatie voltooid en wordt dit bericht afgedrukt als dit succesvol is.

   8096 NOT 11:04:15.173585  SECD: -Successfully obtained a TLS connection
    to the TVS server

5. De telefoon stuurt nu een verzoek om het certificaat te verifiëren.

   8159 NOT 11:04:15.219065  SECD: -Successfully sent the certificate Authentication
    request to TVS server, bytes written : 962
   8160 NOT 11:04:15.219141  SECD: -Done sending Certificate Validation request
   8161 NOT 11:04:15.219218  SECD: -Authenticate Certificate : request sent to
    TVS server - waiting for response

6. Het antwoord "0" van de TVS betekent dat de verificatie succesvol was.

   8172 NOT 11:04:15.220060  SECD: -Authentication Response received, status : 0

7. Dit bericht wordt weergegeven en u ziet het antwoord.

   8185 NOT 11:04:15.221043  SECD: -Authenticated the HTTPS conn via TVS
   
   8198 NOT 11:04:15.296173  CVM-[truncated] Received
            HTTP/1.1 200 OK^M
           X-Frame-Options: SAMEORIGIN^M
           Set-Cookie: JSESSIONID=660646D3655BB00734D3895606BCE76F;
    Path=/ccmcip/; Secure; HttpOnly^M
           Content-Type: text/xml;charset=utf-8^M
           Content-Length: 966^M
           Date: Tue, 30 Sep 2014 11:04:15 GMT^M
           Server:  ^M
           ^M
           <?xml version="1.0" encoding="UTF-8" standalone="yes"?><CiscoIPPhoneInput>
   <Title>Directory Search</Title><Prompt>Enter search criteria</Prompt><SoftKeyItem>
   <Name>Search</Name><Position>1</Position><URL>SoftKey:Submit</URL></SoftKeyItem>
   <SoftKeyItem><Name>&lt;&lt;</Name><Position>2</Position><URL>SoftKey:&lt;&lt;</URL>
   </SoftKeyItem><SoftKeyItem><Name>Cancel</Name><Position>3</Position>
   <URL>SoftKey:Cancel</URL></SoftKeyItem>
   <URL>https://10.106.111.100:8443/ccmcip/xmldirectorylist.jsp</URL>
   <InputItem><DisplayName>First Name</DisplayName>
   <QueryStringParam>f</QueryStringParam><InputFlags>A</InputFlags>
   <DefaultValue></DefaultValue></InputItem><InputItem>
   <DisplayName>Last Name</DisplayName><QueryStringParam>l</QueryStringParam>
   <InputFlags>A</InputFlags><DefaultValue></DefaultValue></InputItem><InputItem>
   <DisplayName>

   Het certificaatverificatieproces is vergelijkbaar met wat wordt besproken in Telefooncontactpersonen Vertrouwensverificatieservice voor onbekend certificaat.

   Van de pakketopnames (PCAP's) die aan het telefoonuiteinde zijn verzameld, kunt u de TVS-communicatie verifiëren met behulp van dit filter - tcp.port==2445.

In de logboeken voor gelijktijdige tv's:

1. Controleer sporen met betrekking tot de handdruk van de Transport Layer Security (TLS).
2. Bekijk vervolgens de inkomende hex-dump.

   04:04:15.270 |   debug ipAddrStr (Phone) 10.106.111.121
   04:04:15.270 |<--debug
   04:04:15.270 |-->debug
   04:04:15.270 |   debug 2:UNKNOWN:Incoming Phone Msg:
   .
   .
   04:04:15.270 |   debug
   HEX_DUMP: Len = 960:
   
   04:04:15.270 |<--debug
   04:04:15.270 |-->debug
   04:04:15.270 |   debug 57 01 01 00 00 00 03 ea
   .
   << o/p omitted >>
   .
   04:04:15.271 |   debug     MsgType               : TVS_MSG_CERT_VERIFICATION_REQ

3. De TVS haalt de gegevens van de uitgever op.

   04:04:15.272 |-->CDefaultCertificateReader::GetIssuerName
   04:04:15.272 |   CDefaultCertificateReader::GetIssuerName got issuer name
   04:04:15.272 |<--CDefaultCertificateReader::GetIssuerName
   04:04:15.272 |-->debug
   04:04:15.272 |   debug tvsGetIssuerNameFromX509 - issuerName :
    CN=cucm10;OU=TAC;O=Cisco;L=Blore;ST=KN;C=IN and Length: 43
   04:04:15.272 |<--debug

4. De TVS verifieert het certificaat.

   04:04:15.272 |   debug tvsGetSerialNumberFromX509 - serialNumber :
    6F969D5B784D0448980F7557A90A6344 and Length: 16
   04:04:15.272 |   debug CertificateDBCache::getCertificateInformation -
    Looking up the certificate cache using Unique MAP ID :
    6F969D5B784D0448980F7557A90A6344CN=cucm10;OU=TAC;O=Cisco;L=Blore;ST=KN;C=IN
   04:04:15.272 |   debug CertificateDBCache::getCertificateInformation -
    Certificate compare return =0
   04:04:15.272 |   debug CertificateDBCache::getCertificateInformation -
    Certificate found and equal

5. De tv stuurt het antwoord naar de telefoon.

   04:04:15.272 |   debug 2:UNKNOWN:Sending CERT_VERIF_RES msg
   04:04:15.272 |   debug     MsgType               : TVS_MSG_CERT_VERIFICATION_RES

De URL van de telefoonservice is ingesteld op Toepassing: Cisco/CorporateDirectory en de telefoon maakt gebruik van HTTP

Opmerking: in plaats van een eerdere firmwareversie van de telefoon te gebruiken, waren de service- en beveiligde service-URL hard gecodeerd naar de HTTP-URL. Dezelfde volgorde van gebeurtenissen wordt echter gezien in de firmware van de telefoon die standaard gebruik maakt van HTTP.

Het configuratiebestand van de telefoon heeft de juiste URL.

<phoneService  type="1" category="0">
<name>Corporate Directory</name>
<url>Application:Cisco/CorporateDirectory</url>
<vendor></vendor>
<version></version>
</phoneService>

Via de logboeken van de telefoonconsole kunt u deze stappen controleren.

7250 NOT 11:44:49.981390  CVM-appLaunchRequest: [thread=AWT-EventQueue-0]
[class=cip.app.G4ApplicationManager] Creating application module -
 Corporate Directory/-838075552
7254 NOT 11:44:50.061552  CVM-_HTTPMakeRequest1: Processing Non-HTTPS URL
7256 NOT 11:44:50.061812  CVM-_HTTPMakeRequest1() theHostname: 10.106.111.100:8080


7265 NOT 11:44:50.233788  CVM-[truncated] Received
         HTTP/1.1 200 OK^M
        X-Frame-Options: SAMEORIGIN^M
        Set-Cookie: JSESSIONID=85078CC96EE59CA822CD607DDAB28C91;
 Path=/ccmcip/; HttpOnly^M
        Content-Type: text/xml;charset=utf-8^M
        Content-Length: 965^M
        Date: Tue, 30 Sep 2014 11:44:50 GMT^M
        Server:  ^M
        ^M
        <?xml version="1.0" encoding="UTF-8" standalone="yes"?><CiscoIPPhoneInput>
<Title>Directory Search</Title><Prompt>Enter search criteria</Prompt><SoftKeyItem>
<Name>Search</Name><Position>1</Position><URL>SoftKey:Submit</URL></SoftKeyItem>
<SoftKeyItem><Name>&lt;&lt;</Name><Position>2</Position><URL>SoftKey:&lt;&lt;</URL>
</SoftKeyItem><SoftKeyItem><Name>Cancel</Name><Position>3</Position>
<URL>SoftKey:Cancel</URL></SoftKeyItem>
<URL>http://10.106.111.100:8080/ccmcip/xmldirectorylist.jsp</URL><InputItem>
<DisplayName>First Name</DisplayName><QueryStringParam>f</QueryStringParam>
<InputFlags>A</InputFlags><DefaultValue></DefaultValue></InputItem><InputItem>
<DisplayName>Last Name</DisplayName><QueryStringParam>l</QueryStringParam>
<InputFlags>A</InputFlags><DefaultValue></DefaultValue></InputItem><InputItem>
<DisplayName>Number</D

Van de pakketopnames ziet u een HTTP GET-verzoek en een succesvolle RESPONS. Dit is de PCAP van CUCM:

Problemen oplossen

Voordat u problemen oplost, verzamelt u de details van het probleem dat eerder is vermeld:

Logboeken verzamelen, indien nodig

• Gelijktijdig pakketopnames vanaf de IP-telefoon en vanaf de CUCM-server (de server die als eerste in zijn CM-groep is waar het HTTP(S)-verzoek naar zou worden verzonden).
• Logboeken van de IP-telefoonconsole.
• Cisco TVS-logs (gedetailleerd).

  Wanneer u de TVS-logs instelt op gedetailleerd, moet de service opnieuw worden opgestart voordat wijzigingen in het traceringsniveau kunnen plaatsvinden. Zie Cisco bug ID CSCuq22327 voor de verbetering om te melden dat het opnieuw opstarten van de service vereist is wanneer logboekniveaus worden gewijzigd.

Voer deze stappen uit om het probleem te isoleren:

Stap 1.

Maak een testservice met deze details:

Service Name : <Any Name>
        Service URL :  http://<CUCM_IP_Address>:8080/ccmcip/xmldirectoryinput.jsp
        Secure-Service URL : http://<CUCM_IP_Address>:8080/ccmcip/xmldirectoryinput.jsp
        Service Category : XML Service
        Service Type : Directories
        Enable : CHECK
        Enterprise Subscription : DO NOT CHECK

Abonneer u nu op deze service op een van de getroffen telefoons:

1. Navigeer naar de pagina Apparaatconfiguratie.
2. Kies Abonneren/Abonnement opzeggen onder Verwante links.
3. Abonneer u op de testservice die u hebt gemaakt.
4. Opslaan, de configuratie toepassen en de telefoon resetten.
   1. Wat u hebt gedaan, ongeacht de FW-versie van de telefoon, die bepaalt of de HTTP- of HTTPS-URL moet worden gebruikt, is deze dwingen om de HTTP-URL te gebruiken.
   2. Toegang tot de Corporate Directory-service via de telefoon.
   3. Als het niet werkt, verzamel dan de eerder genoemde logs en vergelijk ze met het werkscenario dat wordt vermeld in het gedeelte Werkscenario en identificeer waar de afwijking is.
   4. Als het werkt, hebt u op zijn minst bevestigd dat er vanuit het perspectief van de CUCM IP Phone-service geen problemen zijn.
   5. In dit stadium is het probleem hoogstwaarschijnlijk bij de telefoons die de HTTPS-URL gebruiken.
   6. Kies nu een telefoon die niet werkt en ga verder met de volgende stap.

Wanneer het werkt met deze wijziging, moet u beslissen of het OK is om de configuratie te verlaten met het bedrijfsdirectory-verzoek / antwoord dat werkt via HTTP in plaats van HTTPS. HTTPS-communicatie werkt niet vanwege een van de redenen die hierna worden besproken.

Stap 2.

Verzamel de eerder genoemde logs en vergelijk ze met het werkscenario dat wordt vermeld in het gedeelte Werkscenario en identificeer waar de afwijking is.

Dit kan een van deze zaken zijn:

1. De telefoon kan geen contact maken met de TVS-server.
   1. Controleer in de PCAPS de communicatie op poort 2445.
   2. Zorg ervoor dat geen van de netwerkapparaten in het pad deze poort blokkeert.
2. De telefoon neemt contact op met de TVS-server, maar de TLS-handshake mislukt.

   Deze regels kunnen worden afgedrukt in de logboeken van de telefoonconsole:

   5007: NOT 10:25:10.060663 SECD: clpSetupSsl: Trying to connect to IPV4,
    IP: 192.168.136.6, Port : 2445
   5008: NOT 10:25:10.062376 SECD: clpSetupSsl: TCP connect() waiting,
    <192.168.136.6> c:14 s:15 port: 2445
   5009: NOT 10:25:10.063483 SECD: clpSetupSsl: TCP connected,
    <192.168.136.6> c:14 s:15
   5010: NOT 10:25:10.064376 SECD: clpSetupSsl: start SSL/TLS handshake,
    <192.168.136.6> c:14 s:15
   5011: ERR 10:25:10.068387 SECD: EROR:clpState: SSL3 alert
    read:fatal:handshake failure:<192.168.136.6>
   5012: ERR 10:25:10.069449 SECD: EROR:clpState: SSL_connect:failed in SSLv3
    read server hello A:<192.168.136.6>
   5013: ERR 10:25:10.075656 SECD: EROR:clpSetupSsl: ** SSL handshake failed,
    <192.168.136.6> c:14 s:15
   5014: ERR 10:25:10.076664 SECD: EROR:clpSetupSsl: SSL/TLS handshake failed,
    <192.168.136.6> c:14 s:15
   5015: ERR 10:25:10.077808 SECD: EROR:clpSetupSsl: SSL/TLS setup failed,
    <192.168.136.6> c:14 s:15
   5016: ERR 10:25:10.078771 SECD: EROR:clpSndStatus: SSL CLNT ERR,
    srvr<192.168.136.6>

   Zie Cisco bug ID CSCua65618 voor meer informatie.
   
   

3. De telefoon neemt contact op met de TVS-servers en de TLS-handshake is succesvol, maar de TVS kan de ondertekenaar van het certificaat dat de telefoon heeft aangevraagd om te verifiëren, niet verifiëren.

   Hier vindt u fragmenten uit tv-logs:

   De telefoon neemt contact op met de tv.
   
   

   05:54:47.779 |   debug 7:UNKNOWN:Got a new ph conn 10.106.111.121 on 10, Total Acc = 6..
   .
   .
   05:54:47.835 |   debug     MsgType               : TVS_MSG_CERT_VERIFICATION_REQ

   De TVS krijgt de naam van de uitgever.

   05:54:47.836 |-->CDefaultCertificateReader::GetIssuerName
   05:54:47.836 |   CDefaultCertificateReader::GetIssuerName got issuer name
   05:54:47.836 |<--CDefaultCertificateReader::GetIssuerName
   05:54:47.836 |-->debug
   05:54:47.836 |   debug tvsGetIssuerNameFromX509 - issuerName :
    CN=cucmpub9;OU=TAC;O=Cisco;L=Bangalore;ST=KN;C=IN and Length: 49

   Het zoekt het certificaat op, maar kan het niet vinden.

   05:54:47.836 |   debug CertificateCTLCache::getCertificateInformation
    - Looking up the certificate cache using Unique MAP ID :
    62E09123B09A61D20E77BE5BF5A82CD4CN=cucmpub9;OU=TAC;O=Cisco;L=Bangalore;ST=KN;C=IN
   05:54:47.836 |<--debug
   05:54:47.836 |-->debug
   05:54:47.836 |   debug ERROR:CertificateCTLCache::getCertificateInformation
    - Cannot find the certificate in the cache
   05:54:47.836 |<--debug
   05:54:47.836 |-->debug
   05:54:47.836 |   debug getCertificateInformation(cert) : certificate not found

4. HTTPS-verkeer wordt ergens in het netwerk geblokkeerd/gedropt.

   Krijg gelijktijdige PCAP's van de telefoon en de CUCM-server om de communicatie te verifiëren.

Andere scenario's wanneer het probleem "Host Not Found" optreedt

1. De CUCM-server wordt gedefinieerd door de hostnaam en problemen met de naamoplossing.
2. De lijst met TVS-servers is leeg op de telefoon wanneer het bestand xmldefault.cnf.xml wordt gedownload. (In versie 8.6.2 bevat het standaardconfiguratiebestand geen TVS-vermelding vanwege Cisco-bug-ID CSCti64589.)
3. De telefoon kan het TVS-item in het configuratiebestand niet gebruiken omdat het bestand xmldefault.cnf.xml is gedownload. Zie Cisco bug ID CSCuq33297 - Telefoon om TVS-informatie te ontleden uit het standaardconfiguratiebestand.
4. De Corporate Directory werkt niet na een CUCM-upgrade omdat de firmware van de telefoon wordt bijgewerkt naar een latere versie die uiteindelijk het gedrag van het gebruik van HTTPS standaard verandert.