- Start
- /
- Artikel
Local Gateway (LGW) är den exklusiva lösningen för att tillhandahålla lokal PSTN-åtkomst till Cisco Webex Calling -kunder. Det här dokumentet hjälper dig att konfigurera en lokal gateway med CUBE hög tillgänglighet, med aktiva eller vänteläge CUBEs för att säkerställa tillståndssäker failover för aktiva samtal.
Grunderna
Förutsättningar
Innan du distribuerar Cisco Unified Border Element (CUBE) High Availability (HA) som en lokal gateway förWebex Calling, se till att du har en djupgående förståelse för följande begrepp:
-
Layer 2 box-till-box-redundans med CUBE Enterprise för tillståndsbevarande 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 gateway-funktionen förCisco Webex Calling, var noga med den konfiguration 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.
Hårdvara- och mjukvarukomponenter
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.
Show-kommandona och loggarna i den här artikeln är baserade på minsta programvaruversion av Cisco IOS -XE 17.9.1 implementerad på en vCube (CSR 8000v).
Referensmaterial
Här är några detaljerade CUBE HA-konfigurationsguider för olika plattformar:
-
Cisco Preferred Architecture för Cisco Webex Calling - https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Webex CallingLösningsöversikt
Cisco Webex Callingär ett samarbetserbjudande som tillhandahåller ett molnbaserat alternativ för flera klienter till lokal PBX-telefontjänst med flera PSTN-alternativ för kunder.
Den lokala gateway-distributionen (representerad nedan) är fokus för den här artikeln. Trunk in för lokal gateway (lokalbaserad PSTN) Webex Calling möjliggör anslutning till en kundägd PSTN-tjänst. Det ger också anslutning till en lokal IP PBX-distribution, t.ex. 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 är tillämplig på en enskild eller flera platser. 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-to-box-redundans använder infrastrukturprotokollet Redundancy Group (RG) för att bilda ett aktivt/standby-par routrar. Detta par delar samma virtuella IP-adress (VIP) över sina respektive gränssnitt och utbyter kontinuerligt statusmeddelanden. CUBE-sessionsinformation kontrolleras över routrarna så att standby-routern kan ta över alla CUBE-samtalsbehandlingsansvar omedelbart om den aktiva routern går ur drift, vilket resulterar i tillståndsbevarande av signalering och media.
Kontrollpekning är begränsad till anslutna samtal med mediapaket. Samtal i transit är inte markerade (till exempel ett försök- eller ringläge).
I den här artikeln kommer CUBE HA att hänvisa till CUBE High Availability (HA) Layer 2 Box-to-Box (B2B) redundans för tillståndsbevarande av samtal.
Från och med IOS-XE 17.9.1 kan CUBE HA distribueras som en lokal gateway för Cisco Webex Calling trunkdistributioner (lokalbaserad PSTN). Den här artikeln kommer att diskutera designöverväganden och konfigurationer. Figuren visar en typisk CUBE HA-inställning som lokal gateway för en Cisco Webex Calling trunkdistribution.
Redundansgruppsinfrakomponent
Redundancy Group (RG) Infra-komponenten tillhandahåller stöd för box-till-box kommunikationsinfrastruktur mellan de två CUB:erna och förhandlar om det slutliga stabila redundanstillståndet. Denna komponent ger också:
-
Ett HSRP-liknande protokoll som förhandlar om det slutliga redundanstillståndet för varje router genom att utbyta keepalive och hello meddelanden mellan de två CUBEs (via kontrollgränssnittet) —GigabiteThernet3 i figuren ovan.
-
En transportmekanism för att kontrollera signalering 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 betraktas som trafikgränssnitt.
Denna RG-komponent måste konfigureras specifikt för att stödja röst B2B HA.
Virtuell IP (VIP) adresshantering för både signalering och media
B2B HA förlitar sig på VIP för att uppnå redundans. VIP och tillhörande fysiska gränssnitt på båda CUB:erna i CUBE HA-paret måste finnas på samma LAN-undernät. Konfiguration av VIP och bindning av VIP-gränssnittet till en viss röstapplikation (SIP) är obligatoriska för röststöd för B2B HA. Externa enheter som Unified CM Webex Calling åtkomst till SBC, tjänsteleverantör eller proxy använder VIP som destinations-IP-adress för samtal som passerar genom CUBE HA-routrarna. Därför fungerar CUBE HA-paren ur en Webex Calling synvinkel som en enda lokal gateway.
Samtalssignalering och RTP-sessionsinformation för etablerade samtal kontrolleras från den aktiva routern till standby-routern. När den aktiva routern går ner tar Standby-routern över och fortsätter att vidarebefordra RTP-strömmen som tidigare dirigerades av den första routern.
Samtal i ett övergående tillstånd vid tidpunkten för failover bevaras inte efter övergången. Till exempel samtal som inte är helt etablerade ännu eller håller på att ändras med en överförings- eller hållfunktion. Etablerade samtal kan kopplas bort efter övergången.
Följande krav finns för att använda CUBE HA som en lokal gateway för tillståndsfullt failover av samtal:
-
CUBE HA kan inte ha TDM eller analoga gränssnitt samlokaliserade
-
Gig1 och Gig2 kallas 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 du konfigurerar 2 HA-par med samma grupp-id måste RG Control/Data-gränssnitt tillhöra olika lager 2-domäner (vlan, separat switch)
-
Portkanal stöds för både RG-kontroll/data- och trafikgränssnitt
-
All signal/media kommer från/till den virtuella IP-adressen
-
När en plattform laddas om i en CUBE-HA-relation startar den alltid upp som Standby
-
Lägre adress för alla gränssnitt (Gig1, Gig2, Gig3) bör vara på samma plattform
-
Redundansgränssnittsidentifierare, rii bör 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 bindning eftersom de alltid är uppe
-
Flera trafikgränssnitt (SIP/RTP) (Gig1, Gig2) kräver gränssnittsspårning för att konfigureras
-
CUBE-HA stöds inte via en tvärkabelanslutning för RG-Control/Data Link (Gig3)
-
Båda plattformarna måste vara identiska och vara anslutna via en fysisk switch ö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 switch och så vidare.
-
Kan inte avsluta WAN på CUBEs direkt eller Data HA på vardera sidan
-
Både Active/Standby måste vara i samma datacenter
-
Det är obligatoriskt att använda separat L3-gränssnitt för redundans (RG Control/data, Gig3). d.v.s. gränssnitt som används för trafik kan inte användas för HA-minneslistor och kontrollpunkter
-
Vid failover genomgår den tidigare aktiva CUBE en omladdning genom design, vilket bevarar signalering och media
Konfigurera redundans på båda CUB:erna
Du måste konfigurera lager 2 box-till-box-redundans på båda CUBs som är avsedda att användas i ett HA-par för att få upp virtuella IP-adresser.
| 1 |
Konfigurera gränssnittsspårning på global nivå för att spåra gränssnittets status.
Track CLI används i RG för att spåra rösttrafikgränssnittets tillstånd så att den aktiva rutten kommer att ha sin aktiva roll efter att trafikgränssnittet är nere. | ||
| 2 |
Konfigurera en RG för användning med VoIP HA under underläget för programredundans.
Här är en förklaring av fälten som används i den här konfigurationen:
| ||
| 3 |
Aktivera redundans från låda till låda för CUBE-programmet. Konfigurera RG från föregående steg under
redundansgrupp 1 — Att lägga till och ta bort det här kommandot kräver en omladdning för att den uppdaterade konfigurationen ska träda i kraft. Vi laddar om plattformarna efter att all konfiguration har tillämpats. | ||
| 4 |
Konfigurera Gig1- och Gig2-gränssnitten med sina respektive virtuella IP-adresser enligt nedan och använd redundansgränssnittsidentifieraren (rii)
Här är en förklaring av fälten som används i den här konfigurationen:
| ||
| 5 |
Spara konfigurationen för den första CUBE och ladda om den. Plattformen för att ladda om senast är alltid Standby.
När VCUBE-1 har startats helt, spara konfigurationen av VCU BE-2 och ladda om den.
| ||
| 6 |
Kontrollera att box-to-box-konfigurationen fungerar som förväntat. Relevanta utdata markeras med fetstil. Vi laddade om VCUBE-2 sist och enligt designövervägandena; plattformen för att ladda om senast kommer alltid att vara Standby.
Fortsätt sedan med den lokala gateway-konfigurationen (registreringsbaserad eller certifikatbaserad) på båda HA CUB:erna. Se Konfigurera lokal gateway på Cisco IOS XE för Webex Calling. |