- Hjem
- /
- Artikel
Implementer CUBE med høj tilgængelighed som lokal gateway
Lokal gateway (LGW) er den eksklusive løsning til at give lokal PSTN-adgang til Cisco Webex Calling-kunder. Dette dokument hjælper dig med at konfigurere en lokal gateway ved hjælp af CUBE med høj tilgængelighed med aktive eller standby-CUBE'er for at sikre tilstandsfuld failover af aktive opkald.
Grundlæggende
Forudsætninger
Før du installerer Cisco Unified Border Element (CUBE) High Availability (HA) som en lokal gateway til Webex Calling, skal du sørge for, at du har en dyb forståelse af følgende begreber:
-
Lag 2 boks-til-boks-redundans med CUBE Enterprise for tilstandsfuld opkaldsbevaring
Retningslinjerne for konfiguration, der er angivet i denne artikel, forudsætter en dedikeret lokal gatewayplatform 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ørg for, at du overholder CUBE HA-designkravene.
Hardware- og softwarekomponenter
CUBE HA som lokal gateway kræver IOS-XE version 17.9.1 eller nyere og en platform, hvor både CUBE HA- og LGW-funktioner understøttes.
Vis kommandoer og logfiler i denne artikel er baseret på mindste softwareudgivelse af Cisco IOS-XE 17.9.1 implementeret på en vCUBE (CSR 8000v).
Referencemateriale
Her er nogle detaljerede CUBE HA konfigurationsvejledninger til forskellige platforme:
-
Cisco ISR 4K- og 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
-
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
Oversigt over Webex Calling-løsningen
Cisco Webex Calling er et samarbejdstilbud, der giver et cloudbaseret alternativ til en lokal PBX-telefontjeneste med flere PSTN-valgmuligheder for kunder.
Den lokale gateway-udrulning (repræsenteret nedenfor) er fokus for denne artikel. Lokal gateway-trunk (lokalt baseret PSTN) i Webex Calling tillader forbindelse til en kundeejet PSTN-tjeneste. Den giver også forbindelse til en lokal IP PBX-installation som f.eks. Cisco Unified CM. Al kommunikation til og fra skyen er sikret ved hjælp af TLS-transport til SIP og SRTP til medier.
Figuren nedenfor viser en Webex Calling-udrulning uden eksisterende IP PBX og gælder for en enkelt udrulning eller en installation på 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 Redundancy Group (RG) til at danne et aktivt/standby-par routere. Dette par deler den samme virtuelle IP-adresse (VIP) på tværs af deres respektive grænseflader og udveksler løbende statusmeddelelser. CUBE-sessionsoplysninger kontrolleres på tværs af routerparret, hvilket gør det muligt for standby-routeren at overtage alle CUBE-opkaldsbehandlingsopgaver med det samme, hvis den aktive router ophører med at fungere, hvilket resulterer i tilstandsfuld bevaring af signal og medier.
Kontrolvisning er begrænset til forbundne opkald med mediepakker. Opkald i transit kontrolleres ikke (f.eks. en prøvende eller ringende tilstand).
I denne artikel henviser CUBE HA til CUBE High Availability (HA) Layer 2 Box-to-Box-redundans (B2B) for tilstandsfuld opkaldsbevaring.
Fra og med IOS-XE 17.9.1 KAN CUBE HA udrulles som en lokal gateway til udrulninger af Cisco Webex Calling-trunk (lokalt baseret PSTN). Denne artikel omhandler designovervejelser og konfigurationer. Figuren viser en typisk CUBE HA-opsætning som lokal gateway til en udrulning af Cisco Webex Calling-trunk.
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 giver 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 medietilstanden 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 tale-B2B HA.
Virtuel IP-adresseadministration (VIP) til 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-parret skal ligge på det samme LAN-undernet. Konfiguration af VIP og binding af VIP-grænsefladen til et bestemt stemmeprogram (SIP) er obligatorisk for understøttelse af tale-B2B HA. Eksterne enheder som f.eks. Unified CM, Webex Calling-adgangs-SBC, tjenesteudbyder eller proxy bruger VIP som destinations-IP-adresse for opkald, der passerer gennem CUBE HA-routere. Derfor fungerer CUBE HA-par som en enkelt lokal gateway fra et Webex Calling-synspunkt.
Opkaldssignalet og RTP-sessionsoplysningerne for oprettede opkald kontrolleres fra den aktive router til standby-routeren. Når den aktive router går ned, tager standbyrouteren over og fortsætter med at videresende den RTP-stream, der tidligere blev dirigeret af den første router.
Opkald i en midlertidig tilstand på tidspunktet for failover bevares ikke efter skift. For eksempel opkald, der endnu ikke er fuldt etableret eller er ved at blive ændret med en overførsels- eller ventefunktion. Oprettede opkald kan afbrydes efter skift.
Følgende krav findes for brug af CUBE HA som en lokal gateway til tilstandsfuld failover af opkald:
-
CUBE HA kan ikke have TDM eller analoge grænseflader placeret på samme sted
-
Gig1 og Gig2 kaldes trafikgrænseflader (SIP/RTP), og Gig3 er RG-kontrol-/datagrænseflade (Redundancy Group)
-
Der kan ikke placeres mere end 2 CUBE HA-par i det samme lag 2-domæne, et med gruppe-id 1 og den anden med gruppe-id 2. Hvis du konfigurerer 2 HA-par med det 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-/datagrænseflader og trafikgrænseflader
-
Alle signaler/medier stammer fra/til den virtuelle IP-adresse
-
Når en platform genindlæses 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
-
Redundans Interface Identifier, rii skal være entydig for en par-/grænsefladekombination på det samme lag 2
-
Konfiguration på begge CUBE'er skal være identisk, herunder fysisk konfiguration og skal køre på den samme type platform og IOS-XE-version
-
Loopback-grænseflader kan ikke bruges som bind, da de altid er oppe
-
Flere trafikgrænseflader (SIP/RTP) (Gig1, Gig2) kræver, at grænsefladesporing konfigureres
-
CUBE-HA understøttes ikke over en krydsover-kabelforbindelse til RG-kontrol-/datalinket (Gig3)
-
Begge platforme skal være identiske og være tilsluttet via en fysisk switch på tværs af alle tilsvarende grænseflader, for at CUBE HA kan fungere, dvs. GE0/0/0 af CUBE-1 og CUBE-2 skal afsluttes på den samme switch osv.
-
Kan ikke have WAN afsluttet på CUBE'er direkte eller Data HA på nogen side
-
Begge aktive/standby skal være i det samme datacenter
-
Det er obligatorisk at bruge separat L3-grænseflade for redundans (RG-kontrol/data, Gig3). dvs. grænsefladen, der bruges til trafik, kan ikke bruges til HA-keepalives og kontrolpunktning
-
Ved failover gennemgår den tidligere aktive CUBE efter design en genindlæsning, så signal og medier bevares
Konfigurer redundans på begge CUBE'er
Du skal konfigurere lag 2 boks-til-boks-redundans på begge CUBE'er, der er beregnet til brug i et HA-par, for at hente virtuelle IP-adresser.
1 |
Konfigurer grænsefladesporing på globalt niveau for at spore status for grænsefladen.
Spor CLI bruges i RG til at spore tilstanden for taletrafikgrænsefladen, så den aktive rute fjerner sin aktive rolle, når trafikgrænsefladen er nede. | ||
2 |
Konfigurer en RG til brug med VoIP HA under applikationsredundans-undertilstanden.
Her er en forklaring på de felter, der bruges i denne konfiguration:
| ||
3 |
Aktivér boks-til-boks-redundans for CUBE-programmet. 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 al konfigurationen er blevet anvendt. | ||
4 |
Konfigurer Gig1- og Gig2-grænsefladerne med deres respektive virtuelle IP-adresser som vist nedenfor, og anvend redundansgrænsefladeidentifikatoren (rii)
Her er en forklaring på de felter, der bruges i denne konfiguration:
| ||
5 |
Gem konfigurationen af den første CUBE, og genindlæs den. Platformen, der skal genindlæses sidst, er altid standby.
Når VCUBE-1 starter helt, 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 design overvejelser. Platformen til genindlæsning sidst vil altid være Standby. Fortsæt derefter med konfigurationen af den lokale gateway (registreringsbaseret eller certifikatbaseret) på begge HA CUBE'er. Se Konfigurer lokal gateway på Cisco IOS XE til Webex Calling. |