Grunderna
Förutsättningar
Innan du distribuerar CUBE HA som en lokal gateway för Webex Calling ska du se till att du har en djupare förståelse för följande koncept:
Lager 2 box-till-box-redundans med CUBE Enterprise för statusful bevarande av samtal
Konfigurationsriktlinjerna som anges i den här artikeln utgår från en dedikerad lokal gatewayplattform utan någon befintlig röstkonfiguration. Om en befintlig CUBE-företagsdistribution ändras för att även använda den lokala gatewayfunktionen för Cisco Webex Calling ska du vara uppmärksam på konfigurationen som tillämpas för att säkerställa att befintliga samtalsflöden och funktioner inte avbryts och ser till att du följer CUBE HA-designkraven.
Maskinvaru- och programvarukomponenter
CUBE HA som lokal gateway kräver IOS-XE version 16.12.2 eller senare och stöds i följande plattformar:
ISR4000-serien – 4321, 4331, 4351, 4431, 4451, 4461 (IOS-XE 17.2.1r)
CSR1000-serien-vCUBE (1, 2 och 4 vCPU-konfigurationer)
Visa kommandon och loggar i den här artikeln baseras på en minsta programvaruutgåva av Cisco IOS-XE 16.12.2 som implementeras på en vCUBE (CSR1000v). |
Referensmaterial
Här är några utförliga konfigurationsguider för CUBE HA för olika plattformar:
ISR 4K-serien –https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-ISR4K.html
CSR 1000v (vCUBE)-https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-CSR1000v.html
Cisco-favoritarkitektur för Cisco Webex Calling –https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Webex Calling lösning , översikt
Cisco Webex Calling är ett samarbetserbjudande som tillhandahåller molnbaserade alternativ med flera klienter till en lokal PBX-telefontjänst med två PSTN alternativ för kunder:
Molnansluten PSTN leverantör
Lokal gateway
Distribution av lokal gateway (som representeras nedan) är i fokus för den här artikeln. Lokal gateway är alternativet Ta med eget PSTN för Cisco Webex Calling genom att tillhandahålla anslutning till en kundägd PSTN tjänst. Den ger också anslutning till en lokal IP PBX-distribution, till exempel Cisco Unified CM. All kommunikation till och från molnet är säker med TLS-transport för SIP och SRTP för media.
Figuren nedan visar en Webex Calling utan någon befintlig IP PBX och kan tillämpas på en enskild eller multiplatsdistribution. Konfigurationen som beskrivs i den här artikeln baseras på den här distributionen.
Layer 2 Box-till-Box-redundans
CUBE HA layer 2 box-till-box-redundans använder infrastrukturprotokollet Redundansgrupp (RG) för att skapa ett aktivt/standby-par routrar. Detta par delar samma virtuella IP-adress (VIP) över sina respektive gränssnitt och utbyt statusmeddelanden kontinuerligt. CUBE-mötesinformation fungerar inte tillsammans med ett par routrar, vilket gör att standby-routern kan ta alla CUBE-samtalsbearbetningsansvaret omedelbart om den aktiva routern inte används, vilket resulterar i ett aktivt upprätthållande av signalering och media.
Kontrollen som pekar är begränsad till anslutna samtal med mediepaket. Samtal i transport kontrollera inte telefonsamtal (till exempel ett försök eller en ringsignals tillstånd). I den här artikeln hänvisar CUBE HA till CUBE High Availability (HA) Layer 2 Box-to-box (B2B) redundans för statusiga bevarande av samtal |
Från och med IOS-XE 16.12.2 kan CUBE HA distribueras som lokal gateway för Cisco Webex Calling-distributioner och vi kommer att gå över överväganden och konfigurationer i den här artikeln. I denna figur visas en typisk CUBE HA-installation som lokal gateway för en Cisco Webex Calling distribution.
Infrakomponent för redundansgrupp
Redundansgruppskomponenten (RG) Infra tillhandahåller kommunikationsinfrastrukturstöd för box-till-box mellan de två K8-erna och förhandlar fram det slutliga stabile redundanstillståndet. Den här komponenten tillhandahåller även:
Ett HSRP-liknande protokoll som förhandlar fram den slutliga redundansen för varje router genom att byta meddelanden om keepalive och hello-meddelanden mellan de två CUB-erna (via kontrollgränssnittet) – GigabitEthernet3 i figuren ovan.
En transportmekanism för kontroll av signalerings- och medietillstånd för varje samtal från den aktiva till standby-routern (via datagränssnittet)– GigabitEthernet3 i figuren ovan.
Konfiguration och hantering av det virtuella IP-gränssnittet (VIP) för trafikgränssnitten (flera trafikgränssnitt kan konfigureras med samma RG-grupp) – GigabitEthernet 1 och 2 anses vara trafikgränssnitt.
Den här RG-komponenten måste konfigureras specifikt för att stödja röst B2B HA.
Hantering av virtuella IP-adresser (VIP) för både signalering och media
B2B HA är beroende av VIP för att uppnå redundans. VIP och tillhörande fysiska gränssnitt för båda CUBE-erna i CUBE HA-par måste finnas på samma LAN-undernät. Konfiguration av VIP och bindningen för VIP-gränssnittet till ett visst röstprogram (SIP) är obligatorisk för stöd för röst B2B HA. Externa enheter, t.ex. Unified CM, Webex Calling har åtkomst till SBC, tjänsteleverantör eller proxy, använd VIP som destinations-IP-adress för samtal som passera genom CUBE HA-routrar. Cube HA-paren Webex Calling en enda lokal gateway från en annan vy.
Samtalssignalering och RTP-sessionsinformation för uppringda samtal markeras från den aktiva routern till standby-routern. När Active router går ner tar Standby-routern över och fortsätter att vidarebefordra DEN RTP-ström som tidigare har dirigerats av den första routern.
Samtal som är i ett övergående tillstånd vid redundansen kommer inte att bevaras efter switchover. Till exempel samtal som inte etableras fullt ut ännu eller som håller på att ändras med en överförings- eller hold-funktion. Uppr?rade samtal kan kopplas bort efter switchover.
Följande krav finns för att använda CUBE HA som lokal gateway för tillstånds redundans av samtal:
CUBE HA kan inte ha samma TDM- eller analoga gränssnitt
Gig1 och Gig2 kallas för trafikgränssnitt (SIP/RTP) och Gig3 är Redundancy Group (RG) Control/data interface
Högst 2 CUBE HA-par kan placeras i samma lager 2-domän, ett med grupp-ID 1 och det andra med grupp-ID 2. Om 2 HA-par konfigureras med samma grupp-ID måste RG Control/Data-gränssnitt tillhöra olika lager 2-domäner (vlan, separat switch)
Portkanalen har stöd för både RG-kontroll-/data- och trafikgränssnitt
All signalering/media kommer från/till den virtuella IP-adressen
När som helst när en plattform laddas om i ett CUBE-HA-förhållande startar den alltid upp som Vänteläge
Lägre adress för alla gränssnitt (Gig1, Gig2, Gig3) måste vara på samma plattform
Identifieraren för redundansgränssnittet måste vara unik för en par-/gränssnittskombination på samma lager 2
Konfigurationen för både CUB MÅSTE vara identisk, inklusive fysisk konfiguration, och måste köras på samma typ av plattform och version IOS-XE
Loopback-gränssnitt kan inte användas som bindning eftersom de alltid är uppe
Gränssnitt med flera trafik (SIP/RTP) (Gig1, Gig2) kräver att gränssnittsspårning konfigureras
CUBE-HA stöds inte via en korskabelanslutning för RG-kontroll-/datalänken (Gig3)
Båda plattformarna måste vara identiska och anslutas via en fysisk switch över alla på samma sätt gränssnitt för att CUBE HA ska fungera, dvs. GE0/0/0 av CUBE-1 och CUBE-2 måste avslutas på samma sätt och så vidare.
Kan inte ha WAN avslutat på BIN direkt eller Data HA på endera sidan
Både Aktiv/Standby måste vara i samma datacenter
Det är obligatoriskt att använda ett separat L3-gränssnitt för redundans (RG Control/data, Gig3). i.e-gränssnittet som används för trafik kan inte användas för ha hållalives och kontrollpointing
Vid redundans går den tidigare aktiva CUBE igenom en "reload by design", där signalering och media fungerar
Konfigurera redundans på bådaKUB:er
Du måste konfigurera redundans i lager 2 för redundans i lager 2 för bådaKN:er som är avsedda att användas i ett HA-par för att visa virtuella IP-adresser.
1 | Konfigurera gränssnittsspårning på global nivå för att spåra gränssnittets status.
Spåra CLI används i RG för att spåra gränssnittet för rösttrafik, så att den aktiva linjen kommer att ha full aktiv roll när trafikgränssnittet ligger nere. |
||||||
2 | Konfigurera ett RG för användning med VoIP HA under programmets redundans underläge.
Här är en förklaring av de fält som används i den här konfigurationen:
|
||||||
3 | Aktivera redundans i box-till-rutan för CUBE-programmet. Konfigurera RG från föregående steg under
redundans-grupp 1 —För att lägga till och ta bort detta kommando måste den uppdateradekonfigurationen uppdateras. Vi laddar om plattformarna efter att alla konfigurationer har tillämpats. |
||||||
4 | Konfigurera gig1- och Gig2-gränssnitten med respektive virtuella IP-adresser enligt nedan och använd gränssnittsidentifieraren(ri)
Här är en förklaring av de fält som används i den här konfigurationen:
|
||||||
5 | Spara konfigurationen av den första CUBE och läs in den igen. Plattformen för att ladda om senast är alltid Vänteläge.
När VCUBE-1 startar upp helt, spara konfigurationen av VCUBE-2 och ladda om den.
|
||||||
6 | Verifiera att rutan-till-rutan-konfigurationen fungerar som väntat. Relevant utdata markeras i fetstil. Vi laddade om VCUBE-2 senast och enligt designövervägandena kommer plattformen att laddas igen senast alltid vara Standby .
|
Konfigurera en lokal gateway på bådaKUB:er
I vår exempelkonfiguration använder vi följande information från Control Hub för att bygga konfigurationen för lokal gateway på både plattformarna, VCUBE-1 och VCUBE-2. Användarnamnet och lösenordet för den här installationen är följande:
Användarnamn: Hussain1076_LGU
Lösenord: lOV12MEaZx
1 | Se till att en konfigurationsnyckel skapas för lösenordet med kommandona nedan innan den kan användas i inloggningsuppgifterna eller delas. Ange 6 lösenord krypteras med AES-chiffer och denna användardefinierade konfigurationsnyckel.
Här är konfigurationen för lokal gateway som gäller för båda plattformarna baserat på de kontrollhubbensparametrar som visas ovan, spara och läs in igen. SIP Digest-inloggningsuppgifter från Control Hub markeras i fetstil.
För att visa utdata för kommandot har vi laddat om VCUBE-2 följt avVCUBE-1, vilket görVCUBE-1 till standby CUBE och VCUBE-2 till den aktiva CUBE |
2 | När som helst kommer endast en plattform att upprätthålla en aktiv registrering som lokal gateway med åtkomst Webex Calling åtkomst via SBC. Ta en titt på utdata för följande visa kommandon. visa programgrupp 1 för redundans visa sip-ua-registerstatus
Från utdata ovan kan du se att VCUBE-2 är den aktiva LGW som underhåller registreringen med Webex Calling åtkomst SBC, medan utdata från "visa sip-ua registreringsstatus" är tom i VCUBE-1 |
3 | Aktivera nu följande felsökningar på VCUBE-1
|
4 | Simulera failover genom att ge följande kommando på den aktiva LGW, VCUBE-2 i det här fallet.
Omkoppling från AKTIV till STANDBY LGW sker i följande scenario, förutom med CLI som listas ovan
|
5 | Kontrollera om VCUBE-1 har registrerats med Webex Calling åtkomst via SBC. VCUBE-2 skulle ha laddats om nu.
VCUBE-1 är nu aktiv LGW. |
6 | Titta på relevant felsökningslogg på VCUBE-1 när du skickar en SIP-registrering till Webex Calling via den virtuella IP-adressen och får 200 OK.
|