- Hjem
- /
- Artikel
Local Gateway (LGW) er den eksklusive løsning til at levere PSTN-adgang i det lokale miljø til Cisco Webex Calling kunder. Dette dokument hjælper dig med at konfigurere en lokal gateway ved hjælp af CUBE høj tilgængelighed med aktive CUBE'er eller standby-CUBE'er for at sikre tilstandsdygtig failover af aktive opkald.
Grundlæggende
Forudsætninger
Før du installerer Cisco Unified Border Element (CUBE) High Availability (HA) som en lokal gateway forWebex Calling, skal du sørge for, at du har en indgående forståelse af følgende begreber:
-
Layer 2 box-to-box-redundans med CUBE Enterprise til bevarelse af statusfulde opkald
Konfigurationsretningslinjerne i denne artikel antager en dedikeret lokal gateway-platform uden eksisterende stemmekonfiguration. Hvis en eksisterende CUBE-virksomhedsinstallation ændres til også at bruge den lokale gateway-funktion tilCisco Webex Calling, skal du være opmærksom på den anvendte konfiguration for at sikre, at eksisterende opkaldsstrømme og funktionaliteter 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.
Show-kommandoerne og logfilerne i denne artikel er baseret på minimumsudgivelse 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 Foretrukken arkitektur til Cisco Webex Calling - https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Webex CallingLøsningsoversigt
Cisco Webex Callinger et samarbejdstilbud, der giver et skybaseret alternativ med flere lejer til lokale PBX-telefontjenester med flere PSTN-muligheder for kunder.
Den lokale gateway-implementering (repræsenteret nedenfor) er fokus for denne artikel. Trunk in med lokal gateway (lokalbaseret PSTN) Webex Calling giver mulighed for tilslutning til en kundeejet PSTN-tjeneste. Det giver også forbindelse til en lokal IP PBX-implementering, 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 nogen eksisterende IP PBX og kan anvendes til en enkelt installation eller en installation på flere steder. Konfigurationen beskrevet i denne artikel er baseret på denne installation.
Lag 2 boks-til-boks redundans
CUBE HA lag 2 box-to-box-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 standbyrouteren at overtage alle CUBE-opkaldsbehandlingsansvar med det samme, hvis den aktive router går ud af drift, hvilket resulterer i tilstandsbevarelse af signalering og medier.
Kontrollpegning er begrænset til tilsluttede opkald med mediepakker. Opkald i transit er ikke markerede (f.eks. en prøve- eller ringetilstand).
I denne artikel henviser CUBE HA til CUBE High Availability (HA) Layer 2 Box-to-Box (B2B) redundans til statusfuld opkaldsbevarelse.
Fra og med IOS-XE 17.9.1 kan CUBE HA implementeres som en lokal gateway til Cisco Webex Calling trunk-implementeringer (lokalbaseret PSTN). Denne artikel vil diskutere designovervejelser og konfigurationer. Figuren viser en typisk CUBE HA-opsætning som Local Gateway til en Cisco Webex Calling trunk-installation.
Redundansgruppe Infrakomponent
Redundancy Group (RG) Infra-komponenten leverer box-to-box-kommunikationsinfrastrukturunderstøttelse 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 CUB'er (via kontrolgrænsefladen) —GigabiteThernet3 i figuren ovenfor.
-
En transportmekanisme til kontrol af signalering og medietilstand for hvert opkald fra den aktive til standbyrouteren (via datagrænsefladen) —GigabiteThernet3 i figuren ovenfor.
-
Konfiguration og styring af den virtuelle IP (VIP) grænseflade til 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 (VIP) adressestyring til både signalering 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 være placeret på det samme LAN-undernet. Konfiguration af VIP og binding af VIP-grænsefladen til en bestemt stemmeapplikation (SIP) er obligatorisk for tale B2B HA-support. Eksterne enheder såsom Unified CM Webex Calling adgang til SBC, tjenesteudbyder eller proxy bruger VIP som destinations-IP-adresse for de opkald, der krydser gennem CUBE HA-routere. Derfor fungerer CUBE HA-parrene fra et Webex Calling synspunkt som en enkelt lokal gateway.
Opkaldssignaleringen og RTP-sessionsoplysningerne for etablerede opkald kontrolleres fra den aktive router til standbyrouteren. Når den aktive router går ned, overtager Standby-routeren og fortsætter med at videresende RTP-strømmen, der tidligere blev dirigeret af den første router.
Opkald i en forbigående tilstand på tidspunktet for failover bevares ikke efter overgangen. For eksempel opkald, der endnu ikke er fuldt etableret eller er i færd med at blive ændret med en overførsels- eller hold-funktion. Etablerede opkald kan afbrydes efter overgangen.
Følgende krav gælder for at bruge CUBE HA som en lokal gateway til tilstandsdygtig failover af opkald:
-
CUBE HA kan ikke have TDM eller analoge grænseflader samplaceret
-
Gig1 og Gig2 kaldes trafikgrænseflader (SIP/RTP), og Gig3 er Redundancy Group (RG) Control/Data Interface
-
Ikke mere end 2 CUBE HA-par kan placeres 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 Control/Data-grænseflader tilhøre forskellige lag 2-domæner (vlan, separat switch)
-
Portkanal understøttes til både RG-kontrol/data og trafikgrænseflader
-
Alle signaler/medier hentes fra/til den virtuelle IP-adresse
-
Hver gang en platform genindlæses i et CUBE-HA-forhold, starter den altid som Standby
-
Lavere adresse for alle grænseflader (Gig1, Gig2, Gig3) skal være på samme platform
-
Redundansgrænsefladeidentifikator, rii skal være unik for en par/grænsefladekombination på det samme lag 2
-
Konfigurationen på begge CUBE'er skal være identisk inklusive fysisk konfiguration og skal køre på 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 via en crossover-kabelforbindelse til RG-Control/Data Link (Gig3)
-
Begge platforme skal være identiske og være forbundet 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 slutte på den samme switch og så videre.
-
Kan ikke få WAN afsluttet på CUBE'er direkte eller Data HA på begge sider
-
Både Active/Standby skal være i samme datacenter
-
Det er obligatorisk at bruge separat L3-grænseflade til redundans (RG Control/Data, Gig3). dvs. grænseflade, der bruges til trafik, kan ikke bruges til HA-opbevaringslister og checkpointing
-
Ved failover gennemgår den tidligere aktive CUBE en genindlæsning efter design, hvilket bevarer signalering og medier
Konfigurer redundans på begge CUBE'er
Du skal konfigurere lag 2 box-to-box-redundans på begge CUBE'er, der er beregnet til at blive brugt i et HA-par for at få virtuelle IP'er op.
| 1 |
Konfigurer interfacesporing på globalt niveau for at spore grænsefladens status.
Track CLI bruges i RG til at spore stemmetrafikgrænsefladetilstanden, så den aktive rute får sin aktive rolle, når trafikgrænsefladen er nede. | ||
| 2 |
Konfigurer en RG til brug med VoIP HA under programredundansundertilstanden.
Her er en forklaring på de felter, der bruges i denne konfiguration:
| ||
| 3 |
Aktivér box-to-box-redundans for CUBE-programmet. Konfigurer RG fra forrige trin under
redundansgruppe 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 konfiguration er blevet anvendt. | ||
| 4 |
Konfigurer Gig1- og Gig2-grænsefladerne med deres respektive virtuelle IP'er 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 op, skal du gemme konfigurationen af VCUBE-2 og genindlæse den.
| ||
| 6 |
Kontroller, at box-to-box-konfigurationen fungerer som forventet. Relevant output fremhæves med fed skrift. Vi genindlæste VCUBE-2 sidst og i henhold til designovervejelserne; platformen, der skal genindlæses sidst, vil altid være Standby.
Fortsæt derefter med den lokale gateway-konfiguration (registreringsbaseret eller certifikatbaseret) på begge HA CUBE'er. Se Konfigurere lokal gateway på Cisco IOS XE for Webex Calling. |