- Hjem
- /
- Artikkel
Local Gateway (LGW) er den eksklusive løsningen for å gi lokal PSTN-tilgang til Cisco Webex Calling -kunder. Dette dokumentet veileder deg i konfigurering av en lokal gateway ved hjelp av CUBE høy tilgjengelighet, med aktive CUBE-er eller ventemodus for å sikre tilstandsdyktig failover av aktive samtaler.
Grunnleggende
Forutsetninger
Før du distribuerer Cisco Unified Border Element (CUBE) High Availability (HA) som en lokal gateway forWebex 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 tilstandsdyktig anropsbevaring
Konfigurasjonsretningslinjene gitt i denne artikkelen antar en dedikert lokal gateway-plattform uten eksisterende stemmekonfigurasjon. Hvis en eksisterende CUBE-bedriftsdistribusjon blir endret for også å bruke den lokale gateway-funksjonen forCisco Webex Calling, må du være nøye med på konfigurasjonen som brukes for å sikre at eksisterende anropsflyter og funksjonaliteter ikke blir avbrutt, og sørg for at du overholder CUBE HA-designkravene.
Maskinvare- og programvarekomponenter
CUBE HA som lokal gateway krever IOS-XE versjon 17.9.1 eller nyere og en plattform der både CUBE HA- og LGW-funksjoner støttes.
Show-kommandoene og loggene i denne artikkelen er basert på minimum programvareutgivelse av Cisco IOS -XE 17.9.1 implementert på en vCube (CSR 8000v).
Referansemateriale
Her er noen detaljerte CUBE HA-konfigurasjonsveiledninger for ulike plattformer:
-
Cisco Preferred Architecture for Cisco Webex Calling - https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Webex CallingLøsningsoversikt
Cisco Webex Callinger et samarbeidstilbud som gir et skybasert alternativ for flere leietakere til lokal PBX-telefontjeneste med flere PSTN-alternativer for kunder.
Lokal gateway-distribusjon (representert nedenfor) er fokus for denne artikkelen. Lokal gateway (lokalbasert PSTN) trunk-in Webex Calling tillater tilkobling til en kundeeid PSTN-tjeneste. Det 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 media.
Figuren nedenfor viser en Webex Calling distribusjon uten eksisterende IP-PBX og gjelder for en enkelt distribusjon eller en distribusjon på flere steder. Konfigurasjonen beskrevet i denne artikkelen er basert på denne distribusjonen.
Lag 2 boks-til-boks redundans
CUBE HA lag 2 box-to-box-redundans bruker infrastrukturprotokollen Redundancy Group (RG) til å danne et aktivt/standby-par rutere. Dette paret deler den samme virtuelle IP-adressen (VIP) på tvers av sine respektive grensesnitt og utveksler kontinuerlig statusmeldinger. CUBE-øktinformasjon sjekkes på tvers av ruterparet, slik at standby-ruteren kan overta alle CUBE-anropsbehandlingsansvar umiddelbart hvis den aktive ruteren går ut av drift, noe som resulterer i tilstandsdyktig bevaring av signalering og media.
Kontrollpeking er begrenset til tilkoblede samtaler med mediepakker. Anrop i transitt er ikke sjekkpekte (for eksempel en prøve- eller ringetilstand).
I denne artikkelen vil CUBE HA referere til CUBE High Availability (HA) Layer 2 Box-to-Box (B2B) redundans for tilstandsbevarelse av anrop.
Fra og med IOS-XE 17.9.1 kan CUBE HA distribueres som en lokal gateway for Cisco Webex Calling trunk-distribusjoner (lokalbasert PSTN). Denne artikkelen vil diskutere designhensyn og konfigurasjoner. Figuren viser et typisk CUBE HA-oppsett som lokal gateway for en Cisco Webex Calling trunk-distribusjon.
Redundansgruppe Infrakomponent
Redundancy Group (RG) Infra-komponenten gir støtte for box-til-boks kommunikasjonsinfrastruktur mellom de to CUB-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 CUBene (via kontrollgrensesnittet) —GigabiteThernet3 i figuren over.
-
En transportmekanisme for å sjekke signalering og medietilstand for hvert anrop fra den aktive til standby-ruteren (via datagrensesnittet) —GigabiteThernet3 i figuren over.
-
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 spesielt for å støtte tale B2B HA.
Virtuell IP (VIP) adresseadministrasjon for både signalering og media
B2B HA er avhengig av VIP for å oppnå redundans. VIP og tilknyttede fysiske grensesnitt på begge CUBE-ene i CUBE HA-paret må ligge på samme LAN-delnett. Konfigurasjon av VIP og binding av VIP-grensesnittet til en bestemt taleapplikasjon (SIP) er obligatorisk for tale B2B HA-støtte. Eksterne enheter som Unified CM Webex Calling tilgang til SBC, tjenesteleverandør eller proxy, bruker VIP som destinasjons-IP-adresse for samtalene som går gjennom CUBE HA-ruterne. Derfor fungerer CUBE HA-parene fra et Webex Calling synspunkt som en enkelt lokal gateway.
Anropssignalering og RTP-sesjonsinformasjon for etablerte anrop sjekkes fra den aktive ruteren til standby-ruteren. Når den aktive ruteren går ned, tar Standby-ruteren over, og fortsetter å videresende RTP-strømmen som tidligere ble rutet av den første ruteren.
Anrop i en forbigående tilstand på tidspunktet for failover vil ikke bli bevart etter overgangen. For eksempel anrop som ikke er fullstendig etablert ennå, eller som er i ferd med å bli endret med en overførings- eller hold-funksjon. Etablerte samtaler kan kobles fra etter overgangen.
Følgende krav gjelder for bruk av CUBE HA som en lokal gateway for tilstandsdyktig failover av anrop:
-
CUBE HA kan ikke ha TDM eller analoge grensesnitt samlokalisert
-
Gig1 og Gig2 blir referert til som trafikk (SIP/RTP) grensesnitt og Gig3 er Redundancy Group (RG) kontroll/datagrensesnitt
-
Ikke mer enn 2 CUBE HA-par kan plasseres i det samme lag 2-domenet, det ene med gruppe-id 1 og det andre med gruppe-id 2. Hvis du konfigurerer 2 HA-par med samme gruppe-ID, må RG Control/Data-grensesnitt tilhøre forskjellige lag 2-domener (vlan, separat bryter)
-
Portkanal støttes for både RG-kontroll/data- og trafikkgrensesnitt
-
All signalering/media er hentet fra/til den virtuelle IP-adressen
-
Hver gang en plattform lastes på nytt i et CUBE-HA-forhold, starter den alltid opp som Standby
-
Lavere adresse for alle grensesnittene (Gig1, Gig2, Gig3) skal være på samme plattform
-
Redundansgrensesnittidentifikator, rii skal være unik for en par/grensesnittkombinasjon på samme lag 2
-
Konfigurasjonen på begge CUBE-ene må være identisk inkludert fysisk konfigurasjon og må kjøre på samme type plattform og IOS-XE-versjon
-
Loopback-grensesnitt kan ikke brukes som bind, da de alltid er oppe
-
Flere trafikkgrensesnitt (SIP/RTP) (Gig1, Gig2) krever at grensesnittsporing konfigureres
-
CUBE-HA støttes ikke over en tverrkabelforbindelse for RG-kontroll/datalinken (Gig3)
-
Begge plattformene må være identiske og være koblet via en fysisk bryter på tvers av alle like grensesnitt for at CUBE HA skal fungere, dvs. GE0/0/0 av CUBE-1 og CUBE-2 må avsluttes på samme bryter og så videre.
-
Kan ikke få WAN avsluttet på CUBEs direkte eller Data HA på hver side
-
Både Active/Standby må være i samme datasenter
-
Det er obligatorisk å bruke separat L3-grensesnitt for redundans (RG Control/Data, Gig3). dvs. grensesnitt som brukes til trafikk kan ikke brukes til HA-oppbevaringsdata og sjekkpeking
-
Ved failover gjennomgår den tidligere aktive CUBE en reload ved design, som bevarer signalering og medier
Konfigurer redundans på begge CUB-er
Du må konfigurere lag 2 boks-til-boks redundans på begge CUBE-er som er ment å brukes i et HA-par for å få opp virtuelle IP-er.
| 1 |
Konfigurer grensesnittsporing på globalt nivå for å spore statusen til grensesnittet.
Track CLI brukes i RG for å spore stemmetrafikkgrensesnitttilstanden slik at den aktive ruten vil ha en ganske aktiv rolle etter at trafikkgrensesnittet er nede. | ||
| 2 |
Konfigurer en RG for bruk med VoIP HA under undermodus for applikasjonsredundans.
Her er en forklaring på feltene som brukes i denne konfigurasjonen:
| ||
| 3 |
Aktiver boks-til-boks-redundans for CUBE-programmet. Konfigurer RG fra forrige trinn under
redundansgruppe 1 — Legge til og fjerne denne kommandoen krever en omlasting for at den oppdaterte konfigurasjonen skal tre i kraft. Vi laster inn plattformene på nytt etter at all konfigurasjonen er brukt. | ||
| 4 |
Konfigurer Gig1- og Gig2-grensesnittene med deres respektive virtuelle IP-er som vist nedenfor og bruk redundansgrensesnittidentifikatoren (rii)
Her er en forklaring på feltene som brukes i denne konfigurasjonen:
| ||
| 5 |
Lagre konfigurasjonen til den første CUBE og last den inn på nytt. Plattformen som skal lastes sist er alltid Standby.
Etter at VCUBE-1 har startet opp helt, lagrer du konfigurasjonen av VCU BE-2 og laster den på nytt.
| ||
| 6 |
Kontroller at boks-til-boks-konfigurasjonen fungerer som forventet. Relevant utgang er uthevet med fet skrift. Vi lastet inn VCUBE-2 sist og i henhold til designhensynene; plattformen for å laste sist vil alltid være Standby.
Deretter fortsetter du med Local Gateway-konfigurasjonen (registreringsbasert eller sertifikatbasert) på begge HA CUBE-ene. Se Konfigurere lokal gateway på Cisco IOS XE for Webex Calling. |