Fundamentals
Voorwaarden
Voordat u CUBE HA implementeert als lokale gateway voor Webex Calling, moet u na gaan of u de volgende concepten hebt doorbegrepen:
Redundantie van laag 2 box-to-box met CUBE Enterprise voor stateful gespreksbehoud
De configuratierichtlijnen in dit artikel gaan ervan uit dat een speciaal lokaal gatewayplatform zonder bestaande spraakconfiguratie is. Als een bestaande CUBE enterprise-implementatie wordt gewijzigd om ook gebruik te maken van de lokale gatewayfunctie voor Cisco Webex Calling, let dan goed op de configuratie die wordt toegepast om ervoor te zorgen dat bestaande gespreksstromen en functies niet worden onderbroken en zorg dat u aan de ontwerpvereisten voor CUBE HA voldoet.
Onderdelen van hardware en software
CUBE HA als lokale gateway vereist IOS-XE versie 16.12.2 of hoger en een platform waarop zowel CUBE met ha als LGW wordt ondersteund.
De opdrachten en logboeken in dit artikel zijn gebaseerd op de minimale softwareversie van Cisco IOS-XE 16.12.2 die is geïmplementeerd op een vCUBE (CSR1000v). |
Referentiemateriaal
Hier zijn enkele gedetailleerde CUBE HA-configuratiehandleidingen voor verschillende platforms:
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 Voorkeursarchitectuur voor Cisco Webex Calling:https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
overzicht Webex Calling oplossing
Cisco Webex Calling is een samenwerkingsaanbod dat een cloud-gebaseerd alternatief voor meerdere tenants biedt op cloud gebaseerd op PBX-telefoonservice op locatie met meerdere PSTN-opties voor klanten.
De focus van dit artikel is de implementatie van lokale gateway (hieronder weergegeven). Met de lokale gateway (lokale PSTN- trunk in Webex Calling kunt u verbinding maken met een service die eigendom PSTN klant. Het biedt ook verbinding met een IP PBX-implementatie op locatie, zoals Cisco Unified CM. Alle communicatie van en naar de -cloud wordt beveiligd met TLS-transport voor SIP en SRTP voor media.
In de onderstaande afbeelding wordt Webex Calling implementatie weergegeven zonder bestaande IP PBX en is van toepassing op een enkele implementatie of een implementatie met meerdere -site's. De configuratie in dit artikel is gebaseerd op deze implementatie.
Redundantie van laag 2 box-to-Box
De redundantie in CUBE HA-laag 2 box-to-box gebruikt het RG-infrastructuurprotocol (Redundancy Group) om een actief/stand-by paar routers te vormen. Dit paar deelt hetzelfde virtuele IP-adres (VIP) op hun respectievelijke interfaces en wisselt voortdurend statusberichten uit. Informatie over de CUBE-sessie wordt via het paar routers controleren-indien dit de stand-by router in staat stelt om alle verantwoordelijkheden van CUBE-gespreksverwerking direct over te nemen wanneer de actieve router niet meer in gebruik is, wat resulteert in een stateful behoud van signalering en media.
Aanwijzen is beperkt tot verbonden gesprekken met mediapakketten. Gesprekken in de doorvoer controleren niet het controleren (bijvoorbeeld een proberen- of bel status). In dit artikel verwijst CUBE HA naar CUBE-redundantie met hoge beschikbaarheid (HA) Layer 2 Box-to-Box (B2B) voor redundantie op status gespreksbehoud |
Vanaf IOS-XE 16.12.2 kan CUBE HA worden geïmplementeerd als lokale gateway voor implementaties van Cisco Webex Calling-trunks (op locatie gebaseerde PSTN) en in dit artikel behandelen we ontwerpoverwegingen en configuraties. Deze afbeelding toont een typische CUBE HA-installatie als lokale gateway voor een Cisco Webex Calling trunkimplementatie.
Redundantiegroep Infracomponent
De Redundantiegroep (RG) Infra component biedt de box-to-box communicatie-infrastructuur ondersteuning tussen de tweeKUB's en over de uiteindelijke stabiel redundantie status. Dit onderdeel biedt ook het volgende:
Een HSRP-like protocol dat de uiteindelijke redundantietoestand voor elke router bespreekt door keepalive en hallo berichten uit te wisselen tussen de twee GIGABITE's (via de controleinterface) GigabitEthernet3 in de bovenstaande afbeelding.
Een transportmechanisme voor het door geven van de signalering en de media staat voor elk gesprek van de actieve naar de stand-byrouter (via de gegevensinterface)—GigabitEthernet3 in de bovenstaande afbeelding.
Configuratie en beheer van de virtuele IP-interface (VIP) voor de verkeersinterfaces (er kunnen meerdere verkeersinterfaces worden geconfigureerd met dezelfde RG-groep) – GigabitEthernet 1 en 2 worden beschouwd als verkeersinterfaces.
Deze RG-component moet specifiek worden geconfigureerd om spraak B2B HA te ondersteunen.
Beheer van virtuele IP-adressen (VIP) voor zowel signalering als media
B2B HA is afhankelijk van VIP om redundantie te bereiken. De VIP-en gekoppelde fysieke interfaces op beide CUBE's in het CUBE HA-paar moeten zich op hetzelfde LAN-subnet bevinden. Configuratie van de VIP en de binding van de VIP-interface aan een bepaalde spraaktoepassing (SIP) zijn verplicht voor ondersteuning van spraak B2B HA. Externe apparaten zoals Unified CM, Webex Calling SBC, serviceprovider of proxy gebruiken VIP als bestemmings-IP-adres voor de gesprekken die door de CUBE HA-routers worden doorgelaten. Daarom fungeert Webex Calling CUBE HA-combinatie als één lokale gateway.
De gesprekssignalering en informatie over de RTP-sessie van de bestaande gesprekken worden vanaf de actieve router naar de stand-by router bereikt. Wanneer de Actieve router uitgaat, neemt de stand-by router de over en blijft deze de RTP-stream doorsturen die eerder door de eerste router werd gerouteerd.
Oproepen in een tijdelijke status op het moment van failover worden niet behouden na overschakelt. Gesprekken die bijvoorbeeld nog niet volledig tot stand zijn gekomen of die aan het werk zijn met een functie voor overdracht of wacht. Bestaande gesprekken kunnen na het schakelen worden verbroken.
Voor het gebruik van CUBE HA als lokale gateway voor stateful failover van gesprekken bestaat er het volgende:
CUBE HA kan geen TDM- of analoge interfaces op elkaar hebben geplaatst
Gig1 en Gig2 worden aangeduid als verkeersinterfaces (SIP/RTP) en Gig3 is Redundantiegroep (RG) Control/data interface
Er kunnen niet meer dan 2 CUBE HA-koppels worden geplaatst in hetzelfde domein met laag 2, het ene domein met groeps-id 1 en de andere met groeps-id 2. Als twee HA-interfaces met dezelfde groeps-id worden geconfigureerd, moeten RG Control/Data-interfaces tot verschillende layer 2-domeinen behoren (vlan, afzonderlijke switch)
Poortkanaal wordt ondersteund voor zowel RG Control/data- als verkeersinterfaces
Alle signalering/media wordt van/naar het virtuele IP-adres bron
Op elk moment dat een platform opnieuw wordt geladen in een CUBE-HA-relatie, wordt dit altijd op geladen als Stand-by
Een lager adres voor alle interfaces (Gig1, Gig2, Gig3) moet op hetzelfde platform staan
Redundantie-interface-id, rii moet uniek zijn voor een combinatie van pair/interface op dezelfde Layer 2
De configuratie op beide DEE's moet identiek zijn, inclusief de fysieke configuratie, en moet worden uitgevoerd op hetzelfde type platform en op de IOS-XE-versie.
Loopbackinterfaces kunnen niet worden gebruikt als binding omdat deze altijd in gebruik zijn
Voor meerdere verkeerinterfaces (SIP/RTP) (Gig1, Gig2) moet interface tracking zijn geconfigureerd
CUBE-HA wordt niet ondersteund via een kabelverbinding voor de RG-control/datalink (Gig3)
Beide platforms moeten identiek zijn en via een fysieke schakelaar op alle op dezelfde manier interfaces zijn aangesloten zodat CUBE HA kan werken, d.i. GE0/0/0 van CUBE-1 en CUBE-2 moeten op dezelfde schakelaar beëindigen, d.i.
Kan WAN niet rechtstreeks op DE UC's of Data HA aan beide kant beëindigen
Actief/Stand-by moeten zich in hetzelfde datacenter bevindt
Het is verplicht om afzonderlijke L3-interface voor redundantie (RG Control/data, Gig3) te gebruiken. Bijv. de interface die wordt gebruikt voor het verkeer kan niet worden gebruikt voor ha-keepalives en checkpointing
Na de failover wordt de eerder actieve CUBE opnieuw geladen met een ontwerp, met het behouden van signalering en media
Redundantie op beideKUB's configureren
U moet de redundantie van laag 2 box-to-box configureren op beide PAIR's die zijn bestemd voor gebruik in een HA-paar om virtuele IP's op te halen.
1 | Configureer interface traceren op een algemeen niveau om de status van de interface bij te houden.
Track CLI wordt gebruikt in RG om de status van de spraakverkeerinterface te volgen, zodat de actieve route een actieve rol krijgt nadat de verkeersinterface is uit gebruik. |
||||||
2 | Configureer een RG voor gebruik met VoIP met systeem met redundantie in de submodus redundantie van de toepassing.
Hier is een uitleg van de velden die worden gebruikt in deze configuratie:
|
||||||
3 | Schakel redundantie van box-to-box in voor de CUBE-toepassing. Configureer het RG van de vorige stap onder
redundantiegroep 1: voor het toevoegen en verwijderen van deze opdracht moet de bijgewerkteconfiguratie opnieuw worden geladen. De platformen worden opnieuw geladen nadat alle configuratie is toegepast. |
||||||
4 | Configureer de interfaces Gig1 en Gig2 met hun respectievelijke virtuele IP's zoals hieronder getoond en pas de redundantie-interface-id(rii)toe
Hier is een uitleg van de velden die worden gebruikt in deze configuratie:
|
||||||
5 | Sla de configuratie van de eerste CUBE op en laad deze opnieuw. Het platform om als laatste te laden is altijd de stand-by.
Nadat VCUBE-1 volledig is geladen, kunt u de configuratie van VCUBE-2 opslaan en opnieuw laden.
|
||||||
6 | Controleer of de box-to-box-configuratie werkt zoals verwacht. De relevante uitvoer wordt vetgedrukt gemarkeerd. VCUBE-2 is voor het laatst opnieuw geladen en op basis van het ontwerpoverwegingen is het platform om als laatste te laden altijd stand-by.
|
Een lokale gateway configureren op beide GATEWAY's
In onze voorbeeldconfiguratie gebruiken we de volgende trunk-informatie van Control Hub om de configuratie voor lokale gateway te bouwen op beide platforms, VCUBE-1 en VCUBE-2. De gebruikersnaam en het wachtwoord voor deze installatie zijn als volgt:
Gebruikersnaam: Hussain1076_LGU
Wachtwoord: lOV12MEaZx
1 | Zorg ervoor dat een configuratiesleutel voor het wachtwoord is gemaakt, met de onderstaande opdrachten, voordat u deze in de referenties of gedeelde geheimen kunt gebruiken. Type 6-wachtwoorden worden gecodeerd met AES-versleuteling en deze door de gebruiker gedefinieerde configuratiesleutel.
Hier is de configuratie van lokale gateway die van toepassing is op beide platforms op basis van de hierboven weergegeven Control Hub-parameters, opslaan en opnieuw laden. De aanmeldgegevens van SIP Digest in Control Hub wordenvetgedruktgemarkeerd.
Om de uitvoer van de showopdracht weer te geven, hebben we VCUBE-2 opnieuw geladen gevolgd door VCUBE-1 , waardoor VCUBE-1 de stand-by CUBE enVCUBE-2 de actieve CUBE wordt |
2 | Op een bepaald moment behoudt slechts één platform een actieve registratie als de lokale gateway met de Webex Calling toegang tot SBC. Bekijk de uitvoer van de volgende opdrachten. redundantietoepassingsgroep 1 tonen sip-ua-registratiestatus weergeven
Uit de bovenstaande uitvoer kunt u zien dat VCUBE-2 de actieve LGW is die de registratie bijhoudt met Webex Calling-toegang tot SBC, terwijl de uitvoer van de 'sip-ua-registratiestatus weergeven' leeg is in VCUBE-1 |
3 | Schakel nu de volgende foutopsporing in op VCUBE-1
|
4 | Simuleren door de volgende opdracht uit te voeren op de actieve LGW, VCUBE-2 in dit geval.
Naast de hierboven vermelde CLI wordt er in het volgende scenario overschakelt van de ACTIVE naar de STAND-by LGW
|
5 | Controleer of VCUBE-1 is geregistreerd bij Webex Calling SBC. VCUBE-2 zou nu opnieuw zijn geladen.
VCUBE-1 is nu de actieve LGW. |
6 | Bekijk het relevante foutopsporingslogboek in VCUBE-1 dat een SIP-registratie verstuurt naar Webex Calling via het virtuele IP en 200 OK ontvangt.
|