- Start
- /
- Artikel
Implementera hög CUBE-tillgänglighet som lokal gateway
Lokal gateway (LGW) är den exklusiva lösningen för att tillhandahålla lokal PSTN-åtkomst till Cisco Webex Calling-kunder. Det här dokumentet vägleder dig när du konfigurerar en lokal gateway med CUBE med hög tillgänglighet, med aktiva CUBE eller vänteläge för att säkerställa tillståndskänslig felöverlämning av aktiva samtal.
Grundläggande
Förutsättningar
Innan du distribuerar Cisco Unified Border Element (CUBE) High Availability (HA) som en lokal gateway för Webex Calling måste du se till att du har en djup förståelse för följande begrepp:
-
2-lagers enhet-till-enhetsredundans med CUBE Enterprise för tillståndskänsligt bevarande av samtal
Konfigurationsriktlinjerna i den här artikeln förutsätter en dedikerad lokal gateway-plattform 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-samtal 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 se till att du följer CUBE HA-designkraven.
Maskinvaru- och programvarukomponenter
CUBE HA som lokal gateway kräver IOS-XE version 17.9.1 eller senare och en plattform där både CUBE HA- och LGW-funktioner stöds.
Visningskommandon och loggar i den här artikeln baseras på den lägsta programvaruversionen av Cisco IOS-XE 17.9.1 som implementerats på en vCUBE (CSR 8000v).
Referensmaterial
Här är några detaljerade konfigurationsguider för CUBE HA för olika plattformar:
-
Cisco ISR 4K- och Cisco Catalyst 8K-serien – https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m-cube-ha-isr-g3.html
-
CSR 8000v (vCUBE) – https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m-cube-ha-csr.html
-
Föredragen Cisco-arkitektur för Cisco Webex Calling – https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Översikt över Webex Calling-lösning
Cisco Webex Calling är ett samarbetserbjudande som tillhandahåller ett molnbaserat alternativ för flera klienter till en lokal PBX-telefontjänst med flera PSTN-alternativ för kunder.
Distribution av lokal gateway (representerad nedan) är fokus i den här artikeln. Trunk för lokal gateway (platsbaserad PSTN) i Webex Calling möjliggör anslutning till en kundägd PSTN-tjänst. Det ger även anslutning till en lokal IP PBX-distribution, till exempel Cisco Unified CM. All kommunikation till och från molnet är säkrad med TLS-transport för SIP och SRTP för media.
Figuren nedan visar en Webex Calling-distribution utan någon befintlig IP PBX och gäller för en distribution på en eller flera platser. Konfigurationen som beskrivs i den här artikeln baseras på den här distributionen.
Enhet 2-lagers enhet-till-enhetsredundans
CUBE HA 2-lagers enhet-till-enhetsredundans använder infrastrukturprotokollet för redundansgrupp (RG) för att bilda ett aktivt par routrar/vänteläge. Det här paret delar samma virtuella IP-adress (VIP) över sina respektive gränssnitt och utbyter kontinuerligt statusmeddelanden. CUBE-sessionsinformation kontrolleras över ett par routrar så att routern i vänteläge kan ta över allt ansvar för CUBE-samtalsbehandling omedelbart om den aktiva routern tas ur drift, vilket resulterar i tillståndskänslig bevarande av signalering och media.
Kontrollen är begränsad till anslutna samtal med mediapaket. Samtal i transit kontrolleras inte (till exempel ett försök- eller ringtillstånd).
I den här artikeln hänvisar CUBE HA till CUBE High Availability (HA) Layer 2 Box-to-Box (B2B)-redundans för tillståndskänsligt bevarande av samtal.
Från och med IOS-XE 17.9.1 KAN CUBE HA distribueras som en lokal gateway för distributioner av Cisco Webex Calling-trunk (platsbaserad PSTN). I den här artikeln diskuteras designöverväganden och konfigurationer. Figuren visar en typisk CUBE HA-konfiguration som lokal gateway för en Cisco Webex Calling-trunkdistribution.
Infrakomponent för redundansgrupp
Infrakomponenten för redundansgrupp (RG) tillhandahåller stöd för infrastruktur för kommunikation mellan de två CUBE:erna och förhandlar fram det slutliga stabila redundanstillståndet. Den här komponenten tillhandahåller även:
-
Ett HSRP-liknande protokoll som förhandlar om den slutliga redundanstillståndet för varje router genom att utbyta keepalive- och hälsningsmeddelanden mellan de två CUBE (via kontrollgränssnittet) – GigabitEthernet3 i figuren ovan.
-
En transportmekanism för att kontrollera signalerings- och mediestatus för varje samtal från den aktiva routern till vänteläge (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 betraktas som trafikgränssnitt.
Denna RG-komponent måste konfigureras specifikt för att stödja röst B2B HA.
Hantering av virtuell IP (VIP)-adress för både signalering och media
B2B HA förlitar sig på VIP för att uppnå redundans. VIP och associerade fysiska gränssnitt på båda CUBEs i CUBE HA-paret måste finnas på samma LAN-undernät. Konfiguration av VIP och bindning av VIP-gränssnittet till ett visst röstprogram (SIP) är obligatoriskt för stöd för röst B2B HA. Externa enheter som Unified CM, Webex Calling-åtkomst-SBC, tjänsteleverantör eller proxy använder VIP som destinations-IP-adress för samtal som korsar CUBE HA-routrar. Ur Webex Calling-synpunkt fungerar därför CUBE HA-paret som en enda lokal gateway.
Information om samtalssignalering och RTP-session för etablerade samtal kontrolleras från den aktiva routern till routern i vänteläge. När den aktiva routern går ner tar routern i vänteläge över och fortsätter att vidarebefordra RTP-strömmen som tidigare dirigerades av den första routern.
Samtal i ett tillfälligt tillstånd vid redundans tid kommer inte att sparas efter växlingen. Till exempel samtal som inte är helt etablerade än eller som håller på att ändras med en överförings- eller parkeringsfunktion. Etablerade samtal kan kopplas från efter växlingen.
Följande krav gäller för användning av CUBE HA som lokal gateway för tillståndskänslig redundans av samtal:
-
CUBE HA kan inte ha TDM eller analoga gränssnitt på samma plats
-
Gig1 och Gig2 kallas trafikgränssnitt (SIP/RTP) och Gig3 är kontroll-/datagränssnitt för redundansgrupp (RG)
-
Högst två CUBE HA-par kan placeras i samma 2-lagersdomän, ett med grupp-ID 1 och den andra med grupp-id 2. Om 2 HA-par konfigureras med samma grupp-ID måste kontroll-/datagränssnitt för RG tillhöra olika 2-lagersdomäner (vlan, separat växel)
-
Portkanalen stöds för både RG-kontroll/data och trafikgränssnitt
-
Alla signalering/media kommer från/till den virtuella IP-adressen
-
När en plattform laddas om i en CUBE-HA-relation startas den alltid i vänteläge
-
Lägre adress för alla gränssnitt (Gig1, Gig2, Gig3) ska finnas på samma plattform
-
Redundansgränssnittsidentifierare, rii ska vara unik för en par-/gränssnittskombination på samma lager 2
-
Konfigurationen på båda CUBE:erna måste vara identisk inklusive fysisk konfiguration och måste köras på samma typ av plattform och IOS-XE-version
-
Loopback-gränssnitt kan inte användas som bindningar eftersom de alltid är igång
-
Flera trafikgränssnitt (SIP/RTP) (Gig1, Gig2) kräver att gränssnittsspårning konfigureras
-
CUBE-HA stöds inte via en crossover-kabelanslutning för RG-kontroll/datalänken (Gig3)
-
Båda plattformarna måste vara identiska och anslutas via en fysisk växel över alla liknande gränssnitt för att CUBE HA ska fungera, dvs. GE0/0/0 av CUBE-1 och CUBE-2 måste avslutas på samma växel och så vidare.
-
Det går inte att ha WAN terminerat på CUBE direkt eller Data HA på vardera sidan
-
Båda aktiva/vänteläge måste vara i samma datacenter
-
Det är obligatoriskt att använda separat L3-gränssnitt för redundans (RG-kontroll/data, Gig3). d.v.s. gränssnitt som används för trafik kan inte användas för HA-keepalives och kontrollpunkter
-
Vid redundans går den tidigare aktiva CUBE igenom en omladdning efter design, vilket bevarar signalering och media
Konfigurera redundans på båda CUBE
Du måste konfigurera 2-lagers enhet-till-enhetsredundans på båda CUBE:erna som är avsedda att användas i ett HA-par för att skapa 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änssnittstillståndet för rösttrafik så att den aktiva rutten tar bort sin aktiva roll när trafikgränssnittet är nere. | ||
2 |
Konfigurera en RG för användning med VoIP HA i underläget för programredundans.
Här är en förklaring av fälten som används i den här konfigurationen:
| ||
3 |
Aktivera enhet-till-enhet-redundans för CUBE-programmet. Konfigurera RG från föregående steg under
redundansgrupp 1 – För att lägga till och ta bort det här kommandot krävs en ny inläsning för att den uppdaterade konfigurationen ska träda i kraft. Plattformarna läses in igen när all konfiguration har tillämpats. | ||
4 |
Konfigurera Gig1- och Gig2-gränssnitten med sina respektive virtuella IP-adresser enligt nedan och tillämpa redundansgränssnittsidentifieraren (rii)
Här är en förklaring av fälten som används i den här konfigurationen:
| ||
5 |
Spara konfigurationen av den första CUBE och läs in den igen. Plattformen som ska läsas in på nytt är alltid vänteläge.
När VCUBE-1 startar helt sparar du konfigurationen av VCUBE-2 och läser in den igen.
| ||
6 |
Kontrollera att box-till-box-konfigurationen fungerar som förväntat. Relevant output markeras i fetstil. Vi har laddat om VCUBE-2 sist och enligt designöverväganden kommer den plattform som ska läsas in på nytt alltid att vara Vänteläge. Fortsätt sedan med den lokala gatewaykonfigurationen (registreringsbaserad eller certifikatbaserad) på båda HA CUBE:erna. Se Konfigurera lokal gateway på Cisco IOS XE för Webex Calling. |