- Hjem
- /
- Artikel
Implementer CUBE høj tilgængelighed som lokal gateway
Lokal gateway (LGW) er den eneste mulighed for at give lokal PSTN-adgang for Cisco Webex Calling-kunder. Formålet med dette dokument er at hjælpe dig med at opbygge en lokal gatewaykonfiguration ved hjælp af CUBE med høj tilgængelighed, aktive eller standby-CUBE'er til statisk failover af aktive opkald.
Grundlæggende
Forudsætninger
Før du installerer CUBE HA som en lokal gateway til Webex Calling, skal du sørge for, at du har en klar forståelse af følgende koncepter:
Lag 2 boks-til-boks-redundans med CUBE Enterprise for tilstandsfuld opkaldsbevaring
Retningslinjerne for konfiguration, der er angivet i denne artikel, tager udgangspunkt i en dedikeret lokal gateway-platform uden eksisterende stemmekonfiguration. Hvis en eksisterende CUBE-virksomhedsudrulning ændres til også at bruge den lokale gateway-funktion til Cisco Webex Calling, skal du være opmærksom på den konfiguration, der anvendes, for at sikre, at eksisterende opkaldsflows og funktioner ikke afbrydes, og sørge for, at du opfylder kravene til CUBE HA-design.
Hardware- og softwarekomponenter
CUBE HA som lokal gateway kræver IOS-XE version 16.12.2 eller nyere, og en platform, hvor både CUBE HA- og LGW-funktioner understøttes.
Visningskommandoer og logfiler i denne artikel er baseret på en softwareudgivelse ikke mindre end Cisco IOS-XE 16.12.2 implementeret på en vCUBE (CSR1000v).
Referencemateriale
Her er nogle detaljerede konfigurationsvejledninger for CUBE HA til forskellige platforme:
ISR 4K-serie – 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
Ciscos foretrukne arkitektur til Cisco Webex Calling – https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Webex Calling-løsningsoversigt
Cisco Webex Calling er et tilbud til samarbejde, der giver et skybaseret alternativ med flere lejere til den lokale PBX-telefontjeneste med flere PSTN valgmuligheder for kunder.
Den lokale gateway-udrulning (repræsenteret herunder) er fokus for denne artikel. Lokal gateway-trunk (stedbaseret PSTN) i Webex Calling tillader forbindelse til en kundeejet PSTN-tjeneste. Den giver også forbindelse til en lokal IP PBX-udrulning, såsom Cisco Unified CM. Al kommunikation til og fra skyen er sikret ved hjælp af TLS-transport til SIP og SRTP til medier.
Nedenstående figur viser en Webex Calling-udrulning uden eksisterende IP PBX og gælder for en enkelt udrulning eller udrulning for flere steder. Konfigurationen, der er beskrevet i denne artikel, er baseret på denne udrulning.
Lag 2 boks-til-boks-redundans
CUBE HA lag 2 boks-til-boks-redundans bruger infrastrukturprotokollen for redundansgruppe (RG) til at udgøre et par routere (aktiv/standby). Dette par deler den samme virtuelle IP-adresse (VIP) på tværs af deres respektive grænseflader og udveksler kontinuerligt statusmeddelelser. CUBE-sessionsoplysninger bliver kontrolleret på tværs af de to routere, hvilket gør det muligt for standby-routeren at overtage alle CUBE-opkaldsbehandlinger med det samme, hvis den aktive router ophører med at være aktiv, hvilket medfører tilstandsfuld bevaring af signal og medier.
Kontrolpunkter er begrænset til tilsluttede opkald med mediepakker. Opkald i overførsel kontrolleres ikke (for eksempel en forsøger- eller ringetonetilstand).
I denne artikel henviser CUBE HA til CUBE High Availability (HA) (høj tilgængelighed) lag 2 boks-til-boks-redundans (B2B) for tilstandsfuld opkaldsbevaring
Fra og med IOS-XE 16.12.2 kan CUBE HA implementeres som en lokal gateway til udrulninger af Cisco Webex Calling-trunk (lokalt baseret PSTN), og vi vil dække designovervejelser og konfigurationer i denne artikel. Denne figur viser en typisk CUBE HA-opsætning som lokal gateway til en Cisco Webex Calling-trunkudrulning.
Infra-komponent for redundansgruppe
Redundansgruppens (RG) infra-komponent giver understøttelse af boks-til-boks-kommunikationsinfrastruktur mellem de to CUBE'er og forhandler den endelige stabile redundanstilstand. Denne komponent leverer også:
En HSRP-lignende protokol, der forhandler den endelige redundanstilstand for hver router ved at udveksle keepalive- og hello-meddelelser mellem de to CUBE'er (via kontrolgrænsefladen) – GigabitEthernet3 i figuren ovenfor.
En transportmekanisme til kontrolpunktning af signal- og medietilstand for hvert opkald fra den aktive router til standby-routeren (via datagrænsefladen) – GigabitEthernet3 i figuren ovenfor.
Konfiguration og administration af den virtuelle IP-grænseflade (VIP) for trafikgrænsefladerne (flere trafikgrænseflader kan konfigureres ved hjælp af den samme RG-gruppe) – GigabitEthernet 1 og 2 betragtes som trafikgrænseflader.
Denne RG-komponent skal konfigureres specifikt til at understøtte stemme-B2B HA.
Virtuel IP-adresseadministration (VIP) for både signal og medier
B2B HA er afhængig af VIP for at opnå redundans. VIP og tilknyttede fysiske grænseflader på begge CUBE'er i CUBE HA-par skal ligge på det samme LAN-undernet. Konfiguration af VIP og binding af VIP-grænsefladen til en bestemt stemmeapplikation (SIP) er obligatorisk for understøttelse af stemme-B2B HA. Eksterne enheder, såsom Unified CM, Webex Calling tilgår SBC, tjenesteudbydere eller proxy bruger VIP som destinations-IP-adresse til opkald, der passerer gennem CUBE HA-routere. Derfor fungerer CUBE HA-par som en enkelt lokal gateway i Webex Calling-sammenhæng.
Opkaldssignalet og RTP-sessionsoplysningerne for oprettede opkald kontrolleres fra den aktive router til standby-routeren. Når den aktive router går ned, tager standby-routeren over og fortsætter med at videresende RTP-strømmen, som tidligere blev dirigeret af den første router.
Opkald i midlertidig tilstand på tidspunktet for failover bevares ikke efter skiftet. For eksempel opkald, der endnu ikke er helt etableret eller er ved at blive ændret med en overførsels- eller ventefunktion. Oprettede opkald kan blive afbrudt efter skiftet.
Følgende krav eksisterer for at bruge CUBE HA som en lokal gateway til tilstandsfuld failover af opkald:
CUBE HA kan ikke have TDM eller analoge grænseflader placeret sammen
Gig1 og Gig2 kaldes for trafikgrænseflader (SIP/RTP), og Gig3 er redundansgruppe (RG)-kontrol-/datagrænseflade
Ikke mere end 2 CUBE HA-par kan anbringes i det samme lag 2-domæne, det ene med gruppe-id 1 og det andet med gruppe-id 2. Hvis du konfigurerer 2 HA-par med samme gruppe-id, skal RG-kontrol-/datagrænseflader tilhøre forskellige lag 2-domæner (vlan, separat switch)
Portkanal understøttes for både RG-kontrol-/data- og trafikgrænseflader
Alle signaler/medier kommer fra/til den virtuelle IP-adresse
Når som helst en platform bliver geninstalleret i et CUBE-HA-forhold, starter den altid som standby
Lavere adresse for alle grænsefladerne (Gig1, Gig2, Gig3) skal være på den samme platform
Redundansgrænsefladeidentifikatoren rii bør være unik for en par-/grænsefladekombination på det samme lag 2
Konfiguration på begge CUBE'er skal være ens inklusive fysisk konfiguration og skal køre på den samme type platform og IOS-XE version
Loopback-grænseflader kan ikke bruges som binding, da de altid er oppe
Flere trafikgrænseflader (SIP/RTP) (Gig1, Gig2) kræver, at brugergrænsefladesporing konfigureres
CUBE-HA understøttes ikke over en krydskabelforbindelse til RG-kontrol-/datalinket (Gig3)
Begge platforme skal være ens og tilsluttes via en fysisk switch på tværs af alle grænseflader af samme slags, for at CUBE HA kan virke, dvs. at GE0/0/0 for CUBE-1 og CUBE-2 skal slutte på den samme switch og så videre.
Kan ikke have WAN afsluttet på CUBE'er direkte eller Data HA på nogen side
Både aktiv/standby skal være i det samme datacenter
Det er obligatorisk at bruge separat L3-grænseflade for redundans (RG-kontrol/data, Gig3). dvs. at grænsefladen, der bruges til trafik, kan ikke bruges til HA-keepalives og kontrolpunktning
Efter failover gennemgår den tidligere aktive CUBE som standard en genindlæsning, og bevarer signal og medier
Konfigurer redundans på begge CUBE'er
Du skal konfigurere lag 2 boks-til-boks-redundans på begge CUBE'er, som skal bruges i et HA-par for at åbne virtuelle IP-adresser.
1 | Konfigurer grænsefladesporing på globalt niveau for at spore status for brugergrænsefladen.
Track CLI bruges i RG til at spore stemmetrafikgrænsefladetilstanden, så den aktive rute stopper sin aktive rolle, når trafikgrænsefladen er nede. | ||
2 | Konfigurer en RG til brug med VoIP HA under applikationens redundans-undertilstand.
Her er en forklaring på felterne, der bruges i denne konfiguration:
| ||
3 | Aktivér boks-til-boks-redundans for CUBE-applikationen. Konfigurer RG fra det forrige trin under
redundans-gruppe 1 – Tilføjelse og fjernelse af denne kommando kræver en genindlæsning, for at den opdaterede konfiguration kan træde i kraft. Vi genindlæser platformene, når hele konfigurationen er blevet anvendt. | ||
4 | Konfigurer Gig1- og Gig2-grænsefladerne med deres respektive virtuelle IP-adresser som vist nedenfor, og anvend redundansgrænseflade-ID'et(rii)
Her er en forklaring på felterne, der bruges i denne konfiguration:
| ||
5 | Gem konfigurationen af den første CUBE, og genindlæs den. Den platform, som skal genindlæses sidst, er altid standby.
Efter VCUBE-1 starter helt op, skal du gemme konfigurationen af VCUBE-2 og genindlæse den.
| ||
6 | Kontrollér, at konfigurationen af boks-til-boks fungerer som forventet. Relevant output er fremhævet med fed. Vi genindlæste VCUBE-2 sidst, og i henhold til designovervejelserne; platformen, der genindlæses sidste, vil altid være Standby.
|
Konfigurer en lokal gateway på begge CUBE'er
I vores eksempelkonfiguration bruger vi følgende trunkoplysninger fra Control Hub til at oprette den lokale gateway-konfiguration på begge platforme, VCUBE-1 og VCUBE-2. Brugernavnet og adgangskoden til denne opsætning er som følger:
Brugernavn: Hussain1076_LGU
Adgangskode: lOV12MEaZx
1 | Sørg for, at der er oprettet en konfigurationsnøgle til adgangskoden med kommandoerne, der er vist nedenfor, før den kan bruges i legitimationsoplysningerne eller de delte hemmelighedselementer. Type 6-adgangskoder krypteres ved hjælp af AES-kode og denne brugerdefinerede konfigurationsnøgle.
Her er den lokale gateway-konfiguration, der gælder for begge platforme baseret på de Control Hub-parametre, der vises ovenfor, gem og genindlæs. SIP Digest-legitimationsoplysninger fra Control Hub er fremhævet med fed skrift.
For at vise kommando-output, har vi geninstalleret VCUBE-2 efterfulgt af VCUBE-1, hvilket gør VCUBE-1 til standby CUBE og VCUBE-2 til den aktive CUBE |
2 | På et givet tidspunkt vil kun én platform opretholde en aktiv registrering som den lokale gateway med Webex Calling-adgangs-SBC. Se resultatet af de følgende visningskommandoer. vis redundansapplikationsgruppe 1 vis statussen for sip-ua-registeret
Fra ovenstående output kan du se, at VCUBE-2 er den aktive LGW, der opretholder registreringen med Webex Calling-adgangs-SBC, mens resultatet af "vis sip-ua-registerstatus" er tomt i VCUBE-1 |
3 | Aktivér nu følgende fejlretninger på VCUBE-1
|
4 | Efterlign failover ved at anvende følgende kommando på den aktive LGW, VCUBE-2 i dette tilfælde.
Skift fra AKTIV til STANDBY LGW sker også i følgende scenarie ud over den CLI, der er angivet ovenfor
|
5 | Kontrollér, om VCUBE-1 er tilmeldt med Webex Calling-adgangs-SBC. VCUBE-2 vil være genindlæst nu.
VCUBE-1 er nu den aktive LGW. |
6 | Se den relevante fejlfindingslog på VCUBE-1, der sender en SIP REGISTER til Webex Calling via den virtuelle IP og modtager en 200 OK.
|