- Hjem
- /
- Artikkel
Implementer CUBE høy tilgjengelighet som lokal gateway
Local Gateway (LGW) er det eneste alternativet for å gi lokalbasert PSTN-tilgang for Cisco Webex Calling -kunder. Hensikten med dette dokumentet er å hjelpe deg med å bygge en lokal gateway-konfigurasjon ved hjelp av CUBE høy tilgjengelighet, aktive CUBE eller ventemodus for tilstandsfull failover for aktive samtaler.
Grunnleggende informasjon
Forutsetninger
Før du distribuerer CUBE HA som en lokal gateway for Webex Calling, må du sørge for at du har en grundig forståelse av følgende begreper:
-
Lag 2 boks-til-boks-redundans med CUBE Enterprise for bevaring av tilstandsfull samtale
Konfigurasjonsretningslinjene i denne artikkelen forutsetter en dedikert lokal gateway plattform uten eksisterende talekonfigurasjon. Hvis en eksisterende CUBE-bedriftsdistribusjon endres til også å bruke den lokal gateway -funksjonen for Cisco Webex Calling, må du følge nøye med på konfigurasjonen som brukes for å sikre at eksisterende samtaleflyter og funksjoner ikke avbrytes, og at du overholder designkravene for CUBE HA .
Maskinvare og programvarekomponenter
CUBE HA som lokal gateway krever IOS-XE versjon 16.12.2 eller nyere og en plattform der både CUBE HA- og LGW-funksjoner støttes.
Vis-kommandoene og loggene i denne artikkelen er basert på minste programvareutgivelse av Cisco IOS-XE 16.12.2 implementert på en vCUBE (CSR1000v).
Referansemateriale
Her er noen detaljerte CUBE HA-konfigurasjonsveiledninger for forskjellige plattformer:
-
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 Preferred-arkitektur for Cisco Webex Calling– https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Oversikt over Webex Calling Solution
Cisco Webex Calling er et samarbeidstilbud som gir et skybasert alternativ for flere leietakere til lokal PBX- telefontjeneste med flere PSTN-alternativer for kunder.
Den lokale gateway-distribusjonen (representert nedenfor) er fokuset i denne artikkelen. Lokal gateway-trunk (lokalbasert PSTN) i Webex Calling tillater tilkobling til en kundeeid PSTN-tjeneste. Den gir også tilkobling til en lokal IP-PBX-distribusjon, for eksempel Cisco Unified CM. All kommunikasjon til og fra skyen er sikret ved hjelp av TLS-transport for SIP og SRTP for medier.
Figuren nedenfor viser en Webex Calling distribusjon uten eksisterende IP-PBX, og gjelder for én distribusjon eller en distribusjon med flere nettsteder. Konfigurasjonen som er skissert i denne artikkelen, er basert på denne distribusjonen.
Lag 2 Boks-til-boks-redundans
CUBE HA lag 2 boks-til-boks-redundans bruker infrastrukturprotokollen Redundancy Group (RG) til å danne et aktivt ruterepar/ventemoduspar. Dette paret deler den samme virtuelle IP-adresse (VIP) på tvers av sine respektive grensesnitt og utveksler kontinuerlig statusmeldinger. CUBE-øktinformasjonen kontrolleres på tvers av ruterparet, noe som gjør at standby-ruteren kan overta alt CUBE samtalebehandling umiddelbart hvis den aktive ruteren går ut av drift, noe som resulterer i tilstandsmessig bevaring av signalisering og medier.
Kontrollpeking er begrenset til tilkoblede samtaler med mediepakker. Samtaler under overføring er ikke kontrollerte (for eksempel prøve- eller ringestatus).
I denne artikkelen vil CUBE HA referere til CUBE High Availability (HA) Layer 2 Box-to-box (B2B)-redundans for tilstandsfull samtalebevaring
Fra og med IOS-XE 16.12.2 kan CUBE HA distribueres som en lokal gateway for Cisco Webex Calling -trunk-distribusjoner (lokalbasert PSTN), og vi vil dekke utformingshensyn og konfigurasjoner i denne artikkelen. Denne figuren viser et typisk CUBE HA-oppsett som lokal gateway for en Cisco Webex Calling .
Infrakomponent for redundansgruppe
Infra-komponenten for redundansgruppe (RG) gir støtte for boks-til-boks-kommunikasjonsinfrastruktur mellom de to CUBE-ene og forhandler den endelige stabile redundanstilstanden. Denne komponenten gir også:
-
En HSRP-lignende protokoll som forhandler den endelige redundanstilstanden for hver ruter ved å utveksle Keepalive- og Hello-meldinger mellom de to CUBE-ene (via kontrollgrensesnittet) – GigabitEthernet3 i figuren ovenfor.
-
En transportmekanisme for kontroll av signalisering og medietilstand for hver samtale fra den aktive ruteren til standby-ruteren (via datagrensesnittet) – GigabitEthernet3 i figuren ovenfor.
-
Konfigurasjon og administrasjon av det virtuelle IP-grensesnittet (VIP) for trafikkgrensesnittene (flere trafikkgrensesnitt kan konfigureres ved hjelp av samme RG-gruppe) – GigabitEthernet 1 og 2 regnes som trafikkgrensesnitt.
Denne RG-komponenten må konfigureres spesifikt for å støtte tale B2B HA.
Administrasjon av virtuell IP-adresse (VIP) for både signalisering og medier
B2B HA er avhengig av VIP for å oppnå redundans. VIP-grensesnittene og de tilknyttede fysiske grensesnittene på begge CUBE-ene i CUBE HA-paret må ligge på samme LAN-delnett. Konfigurasjon av VIP og binding av VIP-grensesnittet til et bestemt taleprogram (SIP) er obligatorisk for tale B2B HA-støtte. Eksterne enheter som Unified CM, Webex Calling tilgang SBC, tjenesteleverandør eller proxy, bruker VIP som destinasjons-IP-adresse for samtaler som går gjennom CUBE HA-ruterne. Fra et Webex Calling synspunkt fungerer derfor CUBE HA-parene som en enkelt lokal gateway.
Samtalesignalerings- og RTP-øktinformasjonen for etablerte anrop kontrolleres fra den aktive ruteren til standby-ruteren. Når den aktive ruteren går ned, tar ventemodus-ruteren over, og fortsetter å videresende RTP-strøm som tidligere ble rutet av den første ruteren.
Anrop i forbigående tilstand på tidspunktet for failover vil ikke bli bevart etter byttet. For eksempel anrop som ikke er fullstendig etablert ennå, eller som er i ferd med å bli endret med en overførings- eller ventingsfunksjon. Etablerte samtaler kan bli koblet fra etter byttet.
Følgende krav finnes for å bruke CUBE HA som en lokal gateway for tilstandsfull failover for samtaler:
-
CUBE HA kan ikke ha TDM eller analoge grensesnitt samlokalisert
-
Gig1 og Gig2 omtales som trafikkgrensesnitt (SIP/RTP), og Gig3 er grensesnitt for kontroll/data for redundansgruppe (RG)
-
Ikke mer enn 2 CUBE HA-par kan plasseres i det samme lag 2-domenet, ett med gruppe-id 1 og det andre med gruppe-id 2. Hvis du konfigurerer to HA-par med samme gruppe-ID, må RG Control/Data-grensesnitt tilhøre forskjellige lag 2-domener (vlan, egen svitsj)
-
Portkanal støttes for både RG Control/data- og trafikkgrensesnitt
-
All signalisering/medier hentes fra/til den virtuelle IP-adressen
-
Hver gang en plattform lastes inn på nytt i et CUBE-HA-forhold, starter den alltid opp som ventemodus
-
Lavere adresse for alle grensesnitt (Gig1, Gig2, Gig3) skal være på samme plattform
-
Redundansgrensesnittidentifikator, rii må være unik for en par/grensesnittkombinasjon på samme lag 2
-
Konfigurasjonen på begge CUBE-ene må være identiske, inkludert fysisk konfigurasjon, og må kjøre på samme type plattform og IOS-XE-versjon
-
Loopback-grensesnitt kan ikke brukes som binding da de alltid er oppe
-
Grensesnitt for flere trafikk (SIP/RTP) (Gig1, Gig2) krever at grensesnittsporing konfigureres
-
CUBE-HA støttes ikke via en krysset kabeltilkobling for RG-control/datalink (Gig3)
-
Begge plattformene må være det identiske og være koblet til via en fysisk bryter på tvers av alle tilsvarende grensesnitt for at CUBE HA skal fungere, dvs. at GE0/0/0 av CUBE-1 og CUBE-2 må avsluttes på samme svitsj og så videre.
-
Kan ikke avslutte WAN på CUBE-er direkte eller Data HA på begge sider
-
Både Aktiv/Standby må være i samme datasenter
-
Det er obligatorisk å bruke eget L3-grensesnitt for redundans (RG Control/data, Gig3). dvs. grensesnitt som brukes for trafikk, kan ikke brukes til HA keepalives og sjekkpunkter
-
Ved failover går den tidligere aktive CUBE gjennom en designmessig ny innlasting, noe som bevarer signalisering og medier
Konfigurer redundans på begge CUBE-ene
Du må konfigurere lag 2 boks-til-boks-redundans på begge CUBE-ene som skal brukes i et HA-par for å få opp virtuelle IP-er.
1 |
Konfigurer grensesnittsporing på globalt nivå for å spore statusen til grensesnittet.
Spor CLI brukes i RG til å spore tilstanden for taletrafikk , slik at den aktive ruten får ganske sin aktive rolle etter at trafikkgrensesnittet er nede. | ||
2 |
Konfigurer en RG for bruk med VoIP HA i undermodusen for programmets redundans.
Her er en forklaring på feltene som brukes i denne konfigurasjonen:
| ||
3 |
Aktiver boks-til-boks-redundans for CUBE-applikasjonen. Konfigurer RG fra forrige trinn under
redundansgruppe 1 – Å legge til og fjerne denne kommandoen krever en ny innlasting for at den oppdaterte konfigurasjonen skal tre i kraft. Vi laster inn plattformene på nytt etter at all konfigurasjon er tatt i bruk. | ||
4 |
Konfigurer Gig1- og Gig2-grensesnittene med sine respektive virtuelle IP-er som vist nedenfor, og bruk ID-en for redundansgrensesnitt ( rii )
Her er en forklaring på feltene som brukes i denne konfigurasjonen:
| ||
5 |
Lagre konfigurasjonen av den første CUBE-en og last den inn på nytt. Plattformen som skal lastes inn sist, er alltid ventemodus.
Etter VCUBE-1 starter opp fullstendig, lagre konfigurasjonen for VCUBE-2 og last den inn på nytt.
| ||
6 |
Verify that the box-to-box configuration is working as expected. Relevant output is highlighted in bold. We reloaded VCUBE-2 last and as per the design considerations; the platform to reload last will always be Standby. |
Configure a Local Gateway on Both CUBEs
In our example configuration, we’re using the following trunk information from Control Hub to build the Local Gateway configuration on both the platforms, VCUBE-1 and VCUBE-2. The username and password for this setup are as follows:
-
Username: Hussain1076_LGU
-
Password: lOV12MEaZx
1 |
Ensure that a configuration key is created for the password, with the commands shown below, before it can be used in the credentials or shared secrets. Type 6 passwords are encrypted using AES cipher and this user-defined configuration key.
Here is the Local Gateway configuration that will apply to both platforms based on the Control Hub parameters displayed above, save and reload. SIP Digest credentials from Control Hub are highlighted in bold.
To display the show command output, we've reloaded VCUBE-2 followed by VCUBE-1, making VCUBE-1 the standby CUBE and VCUBE-2 the active CUBE |
2 |
At any given time, only one platform will maintain an active registration as the Local Gateway with the Webex Calling access SBC. Take a look at the output of the following show commands. show redundancy application group 1 show sip-ua register status
From the output above, you can see that VCUBE-2 is the active LGW maintaining the registration with Webex Calling access SBC, whereas the output of the “show sip-ua register status” is blank in VCUBE-1 |
3 |
Now enable the following debugs on VCUBE-1
|
4 |
Simulate failover by issuing the following command on the active LGW, VCUBE-2 in this case.
Switchover from the ACTIVE to the STANDBY LGW occurs in the following scenario as well besides the CLI listed above
|
5 |
Check to see if VCUBE-1 has registered with Webex Calling access SBC. VCUBE-2 would have reloaded by now.
VCUBE-1 is now the active LGW. |
6 |
Look at the relevant debug log on VCUBE-1 sending a SIP REGISTER to Webex Calling VIA the virtual IP and receiving a 200 OK.
|