Uitleg en tijdelijke oplossing op CSCvt73723 - WebRTC-server die sessies lekt na grote hoeveelheid sessies die op de server zijn geplaatst

Inleiding

Dit document beschrijft de detectie en tijdelijke oplossing op Cisco bug id CSCvt73723 rond lekkende sessies van WebRTC-server na grote hoeveelheid sessies die op de server zijn geplaatst. Dat kan er uiteindelijk toe leiden dat gebruikers niet kunnen inloggen of als gast meedoen aan WebBridge.

Voorwaarden

Vereisten

Cisco raadt kennis van de volgende onderwerpen aan:

• Cisco Meeting Server (CMS) (CallBridge en WebBridge-component)

Gebruikte componenten

De informatie in dit document is gebaseerd op Cisco Meeting Server en in het bijzonder op de component WebBridge 2 / CMA WebRTC. Dit document is niet van toepassing op de nieuwe WebBridge 3 / CMS Web app component die in versie 2.9 is geïntroduceerd.

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.

CSCvt73723 - WebRTC server lekt sessies na grote hoeveelheid sessies geplaatst op de server

Hoe identificeer je dit insect?

Het symptoom vanuit het perspectief van de eindgebruiker is dat als ze eenmaal de harde limiet hebben bereikt, geen andere gebruikers zich bij een vergadering kunnen aansluiten. In de logboeken, het zien van de webbridge stats (volgens deze FAQ) raken 149 NIET noodzakelijkerwijs betekent dit zijn alle uitgelekte sessies. Dit betekent alleen dat de Web Bridge zijn harde limiet heeft bereikt en dat er geen nieuwe verbindingen mogen worden gemaakt.

"webbridge": INFO : [DEBUGGING] Stats 149, c:3477, d:3170

Berekenen hoeveel van deze gelekte sessies zijn is een beetje ingewikkelder en kan worden gedaan als je NIET de CMA desktop client of iOS client gebruikt. Vanaf versie 2.8 rapporteert de Call Bridge elke 5 minuten het aantal CMA-sessies (CMA WebRTC + CMA desktop client + CMA iOS client). Opmerking: dit wordt gemeld als "CMA": "X/Y" waarbij X het huidige aantal actieve CMA-sessies is en Y de piek in de laatste 5 minuten.

INFO: STATS: {"callLegsPS": 1, "callLegs": "20/24", "CMA": "14/17", "sip": {"std": "0/1", "peer": "6/6"}

Alleen maar omdat een Call Bridge 14 huidige sessies meldt, betekent dat nog niet dat er ook 14 sessies worden gemeld. Deze afbeelding is 1:1 op één enkele gecombineerde server maar in een geclusterde plaatsing kan een zitting van de Brug van het Web een vraag op een verschillende Brug van de Vraag concretiseren (vooral wanneer de lastverdeling wordt toegelaten - die het door gebrek voor CMA is).

Om het totale aantal gelekte sessies in een implementatie te berekenen, hebt u de gecombineerde actieve sessies van ALLE webbridge-stats nodig en dit te vergelijken met de gecombineerde CMA Call Bridge-stats die worden gerapporteerd.

Hoe kunt u dit probleem vermijden?

Afhankelijk van hoe vaak uw implementatie deze situatie raakt (eenmaal per paar dagen of eenmaal per paar weken), moet u worden geadviseerd om hun Webbridge(s) opnieuw te starten, die geen gelekte sessies uitlekt en de actieve sessies op 0 resetten. Begrijpelijk kan dit vervelend zijn als dit een dagelijks karwei wordt, vandaar dat deze taak kan worden gefaciliteerd met een script dat beschikbaar is per het codeblok.

################################################################
#### Cisco Meeting Server ####
#### Webbridge restart ####
#### Workaround for CSCvt73723 ####
#### feedback: willwoo@cisco.com ####
################################################################
#--------------------------------------------------------------
# ---------- DISCLAIMER ----------
#--------------------------------------------------------------
# Please note this script is NOT maintained or supported by Cisco.
# This is to be run at entirely your own risk.
# This script is not intended for redistribution
# Tested with python 3.7.4
#--------------------------------------------------------------
#--------------------------------------------------------------
# ---------- Libraries to import ----------
#--------------------------------------------------------------
import paramiko
import time
import datetime
#--------------------------------------------------------------
#--------------------------------------------------------------
# ---------- Deployment parameters to change ----------
#--------------------------------------------------------------
# WB Inventory - just extend or modify the below to match your deployment requirements.
# Enter the MMP IP of the server (can differ from interface webbridge service is running)
webbridges ={1:"127.0.0.1",2:"127.0.0.1",3:"127.0.0.1",4:"127.0.0.1"}

mmp_username = "admin" # MMP username
mmp_password = "password" # MMP password
#--------------------------------------------------------------
def mmp_webbridge_restart(mmp_address,uname,pword):
conn = paramiko.SSHClient()
conn.set_missing_host_key_policy(paramiko.AutoAddPolicy())
try:
conn.connect(mmp_address, 22, uname, pword)
stdin, stdout, stderr = conn.exec_command('webbridge restart')
time.sleep(1)
conn.close()
print_log_message('Webbridge on server: ' + mmp_address + ' restarted successfully')
except Exception as error:
print_log_message('Failed to restart webbridge on server ' + mmp_address + '. Error:')
print_log_message(str(error))
pass
def print_log_message(message):
time_stamp = datetime.datetime.now(datetime.timezone.utc)
time_stamp = str(time_stamp)
file = open('webbridge_restart_logs.txt', 'a')
file.write(time_stamp + " " + message + "\n")
file.close()
if __name__ == '__main__':
for wb in webbridges:
mmp_webbridge_restart(webbridges[wb], mmp_username, mmp_password)
################################################################

Het script vereist enkele kleine bewerkingen (de aanmeldingsgegevens op lijn 29-30 en IP-adressen van de webbruggen in de implementatie op lijn 27) en mag ALLEEN worden uitgevoerd wanneer er geen verwachte belasting is of tijdens een onderhoudsvenster. Het script controleert niet op actieve sessies en voert simpelweg de 'webbridge reset' opdracht uit op alle vermelde servers die geen actieve Webex-sessie afbreken.

Om dit script te automatiseren, kan dit gedaan worden door een kerntaak in te stellen of op een Windows 10 PC met taakplanner. Ervan uitgaande dat de Win 10 PC Python 3.4+ heeft geïnstalleerd, kunnen ze de volgende stappen volgen:

    1. Taakplanning openen

    2. Selecteer 'Basis taak maken...'

    2.1 Voer een naam / beschrijving in voor deze taak

    2.2 Selecteer welke frequentie en tijden u deze taak wilt uitvoeren (aanbevolen alleen tijdens de daluren, hier weergegeven voor elke zaterdag om 2 uur)

    2.3 Te verrichten actie, selecteer: "Start een programma"

    2.4 Actie:

    * Programma / scripts:  C:\<pad naar python.exe>

    (als u het pad naar python.exe niet kent, kan het worden gevonden door naar cmd te gaan en te typen: python -c "import sys; print(sys.executable)")

    * Argumenten toevoegen (optioneel): webbridge_boost.py (of naam van python script)

    * Start in (optioneel): C:\<path to webbridge_boost.py>

Merk op dat een computer die de juiste taak uitvoert, toegang moet hebben tot de MMP van de geconfigureerde CMS-servers. Nadat het script is uitgevoerd, wordt er een webbridge_boost_logs.txt bestand gemaakt dat details bevat over de herstart van de verschillende WebBridges en over mogelijke storingen. Een voorbeeld wordt getoond met één succesvolle verbinding aan 10.48.79.194 en één die aan 127.0.0.1 ontbreekt (zoals het loopbackadres van PC eigenlijk is).

2020-06-08 14:53:18.149915+00:00 Webbridge on server: 10.48.79.194 restarted successfully 2020-06-08 14:53:19.165543+00:00 Failed to restart webbridge on server 127.0.0.1. Error: 2020-06-08 14:53:19.165543+00:00 [Errno None] Unable to connect to port 22 on 127.0.0.1

Hoe om te testen dat het script goed werkt?

Als u Python de PC hebt geïnstalleerd waar u van plan was om het script uit te voeren, kunt u eerst handmatig op het uitvoeren met de volgende stappen:

1. Open cmd en blader naar de locatie van het script met de 'cd' opdracht
   
   
   
   
2. Start het python bestand met de opdracht 'python webbridge_boost.py'
   
   
   
   
3. Indien u een fout ziet die aangeeft dat de 'paramiko' module niet geïnstalleerd is, moet u een extra bibliotheek installeren met de opdracht 'pip install paramiko'
   
   
   
   
4. Als je klaar bent, kun je het script opnieuw draaien met 'python webbridge_reset.py' (LET OP: dit herstart de webbridge en zorgt ervoor dat de huidige webbridge-verbindingen verbreken)
   
   Als het met succes is uitgevoerd, kunt u de uitkomst ervan controleren in het bestand webbridge_boost_logs.txt.

Wanneer zal dit worden vastgesteld?

Dit is geen nieuwe bug en er is geen plan om dit op de Web Bridge 2 / CMA WebRTC te repareren. De nieuwe Web Bridge 3 / CMS web app (beschikbaar vanaf 2.9) wordt niet beïnvloed door deze bug omdat het volledig opnieuw is ontworpen. Klanten die zwaar worden getroffen door dit moeten overwegen om over te stappen naar de nieuwe CMS web app (hoewel let wel, dit is nog niet de optie pariteit met Web Bridge 2 in de 2.9 release. Controleer de CMS 2.9 en cms web app release notities voor de volledige details hiervan.)

Gerelateerde informatie

• Aantekeningen bij gebreken: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvt73723
• Releaseopmerkingen: https://www.cisco.com/c/en/us/support/conferencing/meeting-server/products-release-notes-list.html
• FAQ
  • https://meeting-infohub.cisco.com/faq/content/43/450/en/how-do-you-check-the-number-of-active-sessions-on-a-web-bridge.html