Pakket

• U moet een standaardpakket selecteren wanneer u een sjabloon maakt (zie Pakketten in het gedeelte Overzicht voor meer informatie. Alle gebruikers aan wie die sjabloon is ingericht, ontvangen het standaardpakket, ongeacht of ze doorstromen of zelf provisioning.

• U kunt de pakketselectie voor verschillende klanten beheren door meerdere sjablonen te maken en verschillende standaardpakketten in elk te selecteren. U kunt vervolgens verschillende provisioningskoppelingen of verschillende adapters voor inrichting per onderneming distribueren, afhankelijk van uw gekozen gebruikersvoorzieningenmethode voor deze sjablonen.

• U kunt het pakket met specifieke abonnees wijzigen vanaf deze standaard, met behulp van de inrichtings-API (zie Integreren met Webex voor BroadWorks Provisioning API in het gedeelte Referentie) of via Partner Hub.

• U kunt het pakket van een abonnee niet wijzigen vanuit BroadWorks. De toewijzing van de geïntegreerde IM&P-service is aan of uit; als de abonnee deze service in BroadWorks heeft toegewezen, wordt het pakket definiëren in de Partner Hub-sjabloon die is gekoppeld aan de inrichtings-URL van de abonnee.

Reseller en ondernemingen of serviceprovider en groepen?

• De manier waarop uw BroadWorks-systeem is geconfigureerd, heeft een invloed op de flow-through provisioning. Als u een reseller bij Enterprise bent, moet u de Enterprise-modus inschakelen wanneer u een sjabloon maakt.
• Als uw BroadWorks-systeem is geconfigureerd in serviceprovider modus, kunt u de Enterprise-modus uitschakelen in uw sjablonen.
• Als u van plan bent om organisaties van klanten in te stellen met behulp van beide BroadWorks-modi, moet u verschillende sjablonen voor groepen en ondernemingen gebruiken.

Verificatiemodus

Hoe verifiëren de abonnees van klanten?

(Optie) Certificaatvereisten voor TLS-bridge Proxy

• Webex toont een openbaar ondertekend clientcertificaat aan de proxy.

• De proxy vertrouwt de interne CISCO-CA die het clientcertificaat heeft ondertekend. U kunt deze CA/keten downloaden via Control Hub en deze toevoegen aan de trust store van de proxy. Het openbaar ondertekende XSP-servercertificaat wordt ook geladen in de proxy.

• De proxy toont het openbaar ondertekende servercertificaat voor Webex.

• Webex vertrouwt de openbare certificeringsstantie (CA) die het servercertificaat van de proxy heeft ondertekend.

• De proxy toont een intern ondertekend clientcertificaat voor de XSP's.

  Dit certificaat moet het toestelveld X509.v3 extension field Extended Key usage hebben ingevuld met de BroadWorks OID 1.3.6.1.4.1.6431.1.1.8.2.1.3 en hetTLS-clientAuth-doel. Bijvoorbeeld.:

  X509v3 extensions:
      X509v3 Extended Key Usage:
          1.3.6.1.4.1.6431.1.1.8.2.1.3, TLS Web Client Authentication

  De CN van het interne certificaat moet zijn bwcticlient.webex.com.

  Houd er bij het genereren van interne clientcertificaten voor de proxy rekening mee dat SAN-certificaten niet worden ondersteund. Interne servercertificaten voor de XSP kunnen SAN zijn. Openbare certificeringsinstanties zijn mogelijk niet bereid certificaten te ondertekenen met de eigen broadworks OID die vereist is. In het geval van een gebridgingsproxy moet u mogelijk een interne CA gebruiken om het clientcertificaat te ondertekenen dat de proxy voor de XSP presenteert.

• De XSP's vertrouwen de interne CA.

• De XSP's presenteren een intern ondertekend servercertificaat.

• De proxy vertrouwt de interne ca.

• De ClientIdentity van de toepassingsserver bevat de cn van het intern ondertekende clientcertificaat dat door de proxy aan de XSP wordt gepresenteerd.

(Optie) Certificaatvereisten voor TLS-passthrough Proxy of XSP in DMZ

• Webex presenteert een intern door CA ondertekend clientcertificaat van Cisco voor de XSP's.

• De XSP's vertrouwen de interne Cisco-CA die het clientcertificaat heeft ondertekend. U kunt deze CA/keten downloaden via Control Hub en deze toevoegen aan de trust store van de proxy. Het openbaar ondertekende XSP-servercertificaat wordt ook geladen in de XSP's.

• De XSP's presenteren de openbaar ondertekende servercertificaten aan Webex.

• Webex vertrouwt de openbare CA die de XSP's servercertificaten heeft ondertekend.

• De ClientIdentity van de toepassingsserver bevat de cn van het door Cisco ondertekende clientcertificaat dat door Webex aan de XSP wordt getoond.

Hoe Cisco Webex Cloud XSP-adressen vindt

Cisco Webex Cloud-services voert een DNS A/AAAA-look uit van de geconfigureerde XSP-hostnaam en maakt verbinding met het geretourneerde IP-adres. Dit kan een load balancing edge-element zijn of de XSP-server zelf. Als er meerdere IP-adressen worden geretourneerd, wordt de eerste vermelding in de lijst geselecteerd.

Voorbeelden 2 & 3 hieronder tonen de toewijzing van A/AAAA-records aan één en meerdere IP-adressen.

Hoe Webex-apps XSP-adressen vinden

De client probeert de XSP-knooppunten te vinden met behulp van de volgende DNS-flow:

1. De client haalt aanvankelijk de URL's voor Xsi-Acties/Xsi-Events op vanuit Cisco Webex Cloud (u hebt deze ingevoerd bij het maken van de gekoppelde BroadWorks-belcluster). De Xsi-hostnaam/het domein wordt geparseerd met de URL en de client voert SRV een volgende zoekactie uit:

   1. Client voert een SRV-zoekactie naar uit_xsi-client._tcp.<xsi domain>

      (Zie het volgende voorbeeld 1)

   2. Als de SRV een of meer richtingen retourneert:

      De client doet een A/AAAA-zoekactie naar de geretourneerde IP-adressen en caches.

      Elke A/AAAA-record moet aan één IP-adres worden gemapt. We verplicht deze configuratie omdat de hartslagen voor de XSI-gebeurtenis van de client naar hetzelfde IP-adres moeten gaan dat wordt gebruikt om het gebeurteniskanaal tot stand te helpen. Als u de A/AAAA-naam toekent aan meer dan één IP-adres, verzendt de client uiteindelijk de hartslag naar een adres waar de client geen gebeurteniskanaal tot stand heeft gebracht. Hierdoor wordt het kanaal afgebroken en wordt het interne verkeer aanzienlijk groter, wat de prestaties van uw XSP-cluster beïnvloedt.

      De client maakt verbinding met een van de doelen (en daarom het A/AAAA-record met één IP-adres) op basis van de SRV-prioriteit en vervolgens het gewicht (of willekeurig als ze allemaal gelijk zijn).

   3. Als de SRV niet de volgende doelen wer:

      De client zoekt de Xsi-hoofdparameter a/AAAA en probeert vervolgens verbinding te maken met het geretourneerde IP-adres. Dit kan een load balancing edge-element zijn of de XSP-server zelf.

      Zoals hierboven vermeld, moet de A/AAAA-record voor dezelfde redenen worden opgelost naar één IP-adres.

      (Zie het volgende voorbeeld 2)

2. (Optioneel) Vervolgens kunt u aangepaste XSI-Acties/XSI-Events-gegevens verstrekken in de apparaatconfiguratie voor de Webex-app, met behulp van de volgende tags:

   
   <protocols>
       <xsi>
           <paths>
               <root>%XSI_ROOT_WXT%</root>
               <actions>%XSI_ACTIONS_PATH_WXT%</actions>
               <events>%XSI_EVENTS_PATH_WXT%</events>
           </paths>
       </xsi>
   </protocols>

   1. Deze configuratieparameters hebben voorrang op elke configuratie in uw BroadWorks-cluster in Control Hub.

   2. Als deze bestaan, wordt de client vergeleken met het oorspronkelijke XSI-adres dat het heeft ontvangen via de broadWorks-clusterconfiguratie.

   3. Als er verschil is gedetecteerd, wordt de XSI-acties/XSI Events-verbinding van de client opnieuw initialiseren. De eerste stap in dit proces is hetzelfde DNS-opzoekproces uit te voeren dat onder stap 1 wordt weergegeven. Dit keer verzoekt u een opzoekactie voor de waarde in de%XSI_ROOT_WXT%van het configuratiebestand in.

      Zorg dat u de bijbehorende records SRV maken als u deze tag gebruikt om de Xsi-interfaces te wijzigen.

Voorbeeld van DNS-records

Als u uw DNS A/AAAA-record toekent aan meerdere IP-adressen (om redundante verbindingen voor de microservices te bieden, zoals getoond in de vorige tabel), mag u hetzelfde A/AAAA-record niet gebruiken als het XSI-adres van de clients. In dat geval kunt u een SRV-record configureren voor de clients (zoals getoond in tabel 1 hierboven), maar de SRV moet een andere set A/AAAA-recordsvinden. Zoals eerder vermeld, moeten deze A/AAAA-records aan elk ip-adres worden map.

XSP-knooppunten DNS-aanbevelingen

• U moet één A/AAAA-record gebruiken als u een load balancing reverse proxy moet oplossen voor de XSP-servers.

• U mag alleen round-robin A/AAAA-records gebruiken als:

  • u hebt meerdere XSP-servers op internet die u wilt dat de Webex-microservices vinden.

  • u gebruikt niet de A/AAAA-records om het XSI-adres van de client op te lossen.

• U moet DNS-servicedetectie gebruiken als u:

  • Directory zoeken nodig in omgevingen met meerdere XSP's.

  • Al bestaande integraties hebben waarvoor detectie SRV vereist.

  • Heeft unieke configuraties waarbij standaard A/AAAA-records onvoldoende zijn.