- Start
- /
- Artikel
CUBE met hoge beschikbaarheid implementeren als lokale gateway
De lokale gateway (LGW) is de enige optie om PSTN-toegang op locatie te bieden voor Cisco Webex Calling-klanten. Het doel van dit document is u te helpen bij het bouwen van een configuratie van de lokale gateway met behulp van CUBE met hoge beschikbaarheid, actieve of stand-by CUBE's voor stateful failover van actieve gesprekken.
Basisbeginselen
Voorwaarden
Voordat u CUBE HA implementeert als lokale gateway voor Webex Calling, moet u de volgende concepten begrijpen:
-
Box-to-boxredundantie van datalinklaag met CUBE Enterprise voor toestandsafhankelijk gespreksbehoud
De configuratierichtlijnen in dit artikel gaan uit van een speciaal lokaal gatewayplatform zonder bestaande spraakconfiguratie. Als een bestaande CUBE-bedrijfsimplementatie wordt gewijzigd om ook de lokale gatewayfunctie te gebruiken voor Cisco Webex Calling, let dan goed op de toegepaste configuratie en zorg ervoor dat bestaande gespreksstromen en de bestaande functionaliteiten niet worden onderbroken en zorg dat u voldoet aan de CUBE HA-ontwerpvereisten.
Hardware- en softwareonderdelen
CUBE HA als lokale gateway vereist IOS-XE versie 16.12.2 of hoger en een platform waarop de functies van zowel CUBE HA als LGW worden ondersteund.
De weergaveopdrachten 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:
-
ISR 4K-serie: 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
-
Voorkeursarchitectuur voor Cisco Webex Calling: https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Overzicht van Webex Calling-oplossing
Cisco Webex Calling is een samenwerkingsoplossing die een cloud-gebaseerd alternatief voor meerdere tenants biedt voor PBX-telefoonservice op locatie met meerdere PSTN-opties voor klanten.
De focus van dit artikel is de implementatie van de lokale gateway (hieronder weergegeven). Met de lokale gatewaytrunk (PSTN op locatie) in Webex Calling kunt u verbinding maken met een PSTN-service van de 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 een Webex Calling-implementatie weergegeven zonder bestaande IP PBX. De afbeelding is van toepassing op een enkele implementatie of een implementatie voor meerdere sites. De configuratie in dit artikel is gebaseerd op deze implementatie.
Box-to-boxredundantie van datalinklaag
De box-to-boxredundantie in CUBE HA-datalinklaag gebruikt het RG-infrastructuurprotocol (Redundancy Group) om een paar te vormen van een actieve en stand-byrouter. Dit paar heeft hetzelfde virtuele IP-adres (VIP) op hun respectievelijke interfaces en wisselt voortdurend statusberichten uit. Informatie over de CUBE-sessie wordt via het paar routers op bepaalde punten gecontroleerd, zodat de stand-byrouter alle verantwoordelijkheden van CUBE-gespreksverwerking meteen over kan nemen wanneer de actieve router niet meer in gebruik is. Zo kunnen signalering en media toestandsafhankelijk worden behouden.
Controleren op bepaalde punten is beperkt tot verbonden gesprekken met mediapakketten. Gesprekken in transit worden niet gecontroleerd (bijvoorbeeld een poging of tijdens het overgaan).
In dit artikel verwijst CUBE HA naar box-to-boxredundantie (B2B) van datalinklaag met hoge beschikbaarheid (HA) voor toestandsafhankelijk gespreksbehoud
Vanaf IOS-XE 16.12.2 kan CUBE HA worden geïmplementeerd als lokale gateway voor implementaties van Cisco Webex Calling-trunks (PSTN op locatie) 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.
Infracomponent redundantiegroep
Het infracomponent van de redundantiegroep biedt de box-to-boxcommunicatie infrastructuurondersteuning tussen de twee CUBE's en onderhandelt de uiteindelijke stabiele redundantiestatus. Dit infracomponent biedt ook het volgende:
-
Een HSRP-achtig protocol dat de uiteindelijke redundantiestatus voor elke router onderhandelt door keepalive- en hello-berichten uit te wisselen tussen de twee CUBE's (via de controle-interface) – GigabitEthernet3 in de bovenstaande afbeelding.
-
Een transportmechanisme voor het controleren van de signalering en de mediastatus voor elk gesprek van de actieve naar de stand-byrouter (via de gegevensinterface) – GigabitEthernet3 in de bovenstaande afbeelding.
-
Configuratie en beheer van de VIP-interface (virtuele IP) voor de verkeersinterfaces (er kunnen meerdere verkeersinterfaces worden geconfigureerd met dezelfde RG-groep) – GigabitEthernet 1 en 2 worden beschouwd als verkeersinterfaces.
Dit RG-onderdeel moet specifiek worden geconfigureerd om spraak-B2B HA te ondersteunen.
Beheer van virtuele IP-adressen (VIP) voor zowel signalering als media
B2B HA vertrouwt op 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 het CUBE HA-paar voor Webex Calling als één lokale gateway.
De gesprekssignalering en informatie over de RTP-sessie van de bestaande gesprekken worden op bepaalde punten gecontroleerd tussen de actieve router en de stand-byrouter. Wanneer de actieve router wordt uitgeschakeld, neemt de stand-byrouter het over en blijft deze de RTP-stream doorsturen die eerder door de eerste router werd gerouteerd.
Gesprekken die op het moment van failover in transit zijn, worden na de overschakeling niet voortgezet. Dit zijn gesprekken die bijvoorbeeld nog niet volledig tot stand zijn gekomen of worden bewerkt met een overdrachts- of wachtrijfunctie. Bestaande gesprekken kunnen na het overschakelen worden verbroken.
Voor het gebruik van CUBE HA als lokale gateway voor toestandsafhankelijke failover van gesprekken bestaan de volgende vereisten:
-
CUBE HA kan geen TDM- of analoge interfaces op dezelfde locatie hebben
-
Gig1 en Gig2 worden aangeduid als verkeersinterfaces (SIP/RTP) en Gig3 is een controle-/data-interface voor de redundantiegroep (RG)
-
Er kunnen niet meer dan twee CUBE HA-paren in hetzelfde datalinklaagdomein worden geplaatst: één domein met groeps-id 1 en het andere met groeps-id 2. Als twee HA-paren met dezelfde groeps-id worden geconfigureerd, moeten RG-controle-/data-interfaces tot verschillende datalinklaagdomeinen behoren (vlan, afzonderlijke switch)
-
Poortkanaal wordt ondersteund voor zowel RG-controle-/data- als verkeersinterfaces
-
Alle signalering/media zijn afkomstig van of worden uitgegeven naar het virtuele IP-adres
-
Wanneer een platform in een CUBE HA-relatie wordt herladen, wordt het altijd als stand-by gestart
-
Een lager adres voor alle interfaces (Gig1, Gig2, Gig3) moet zich op hetzelfde platform bevinden
-
De redundantie-interface-id (rii) moet uniek zijn voor een paar/interfacecombinatie op dezelfde datalinklaag
-
De configuratie op beide CUBE's moet identiek zijn, inclusief de fysieke configuratie, en moet worden uitgevoerd op hetzelfde type platform en dezelfde IOS-XE-versie
-
Loopbackinterfaces kunnen niet worden gebruikt als binding, omdat deze altijd actief zijn
-
Voor meerdere verkeerinterfaces (SIP/RTP) (Gig1, Gig2) moet interfacetracering zijn geconfigureerd
-
CUBE-HA wordt niet ondersteund via een kabelverbinding voor de RG-controle-/datakoppeling (Gig3)
-
Beide platforms moeten identiek zijn en moeten op alle soortgelijke interfaces via een fysieke schakelaar zijn verbonden om CUBA HA te laten werken. GE0/0/0 van CUBE-1 en CUBE-2 moet bijvoorbeeld op dezelfde schakelaar worden beëindigd, enzovoort.
-
Kan WAN niet rechtstreeks op CUBE's of data-HA aan een van beide kanten beëindigen
-
De actieve en stand-by moeten zich in hetzelfde datacenter bevinden
-
Het is verplicht om afzonderlijke L3-interfaces voor redundantie (RG-controle/data, Gig3) te gebruiken. De interface die wordt gebruikt voor het verkeer kan bijvoorbeeld niet worden gebruikt voor HA-keepalives en controles op bepaalde punten
-
Bij failover wordt de eerder actieve CUBE bewust herladen, met behoud van de signalering en media
Redundantie op beide CUBE's configureren
U moet de box-to-boxredundantie van datalinklaag configureren op beide CUBE's die bedoeld zijn voor gebruik met een HA-paar voor het ophalen van virtuele IP-adressen.
1 |
Configureer de algemene interfacetracering om de status van de interface bij te houden.
Tracerings-CLI wordt in RG gebruikt om de status van de spraakverkeerinterface te volgen, zodat de actieve router zijn actieve rol beëindigt nadat de verkeersinterface is uitgeschakeld. | ||
2 |
Configureer een RG voor gebruik met VoIP HA onder de submodus voor toepassingsredundantie.
Hier is een uitleg van de velden die worden gebruikt in deze configuratie:
| ||
3 |
Schakel box-to-boxredundantie in voor de CUBE-toepassing. Configureer het RG van de vorige stap onder
redundancy-group 1: voor het toevoegen en verwijderen van deze opdracht moet de bijgewerkte configuratie opnieuw worden geladen. De platformen worden herladen 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 dat het laatst wordt geladen 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-boxconfiguratie werkt zoals verwacht. De relevante uitvoer wordt vetgedrukt. We hebben VCUBE-2 als laatste opnieuw geladen en volgens de ontwerpoverwegingen. Het platform dat het laatst opnieuw wordt geladen, wordt altijd de stand-by. |
Een lokale gateway configureren op beide CUBE's
In onze voorbeeldconfiguratie gebruiken we de volgende trunk-informatie van Control Hub om de configuratie voor de lokale gateway op beide platforms te bouwen, VCUBE-1 en VCUBE-2. De gebruikersnaam en het wachtwoord voor deze installatie zijn als volgt:
-
Gebruikersnaam: Hussain1076LGU_
-
Wachtwoord: lOV12MEaZx
1 |
U moet een configuratiesleutel voor het wachtwoord maken, met behulp van de onderstaande opdrachten, voordat u deze kunt gebruiken in de aanmeldgegevens of gedeelde geheimen. Type 6-wachtwoorden worden gecodeerd met AES-versleuteling en deze door de gebruiker gedefinieerde configuratiesleutel.
Dit is de lokale gateway configuratie die van toepassing is op beide platforms op basis van de Control hub-parameters die hierboven worden weergegeven, opslaan en opnieuw laden. SIP Digest-aanmeldgegevens van Control Hub worden vetgedrukt gemarkeerd.
Voor een weergave van de weergaveopdrachtuitvoer hebben we VCUBE-2 opnieuw geladen, gevolgd door VCUBE-1, waardoor VCUBE-1 de stand-by CUBE is en VCUBE-2 de actieve CUBE |
2 |
Op elk moment behoudt slechts één platform een actieve registratie als lokale gateway met de Webex Calling-toegangs-SBC. Bekijk de uitvoer van de volgende weergaveopdrachten. redundantietoepassingsgroep 1 weergeven status sip-ua-register weergeven
Aan de bovenstaande uitvoer kunt u zien dat VCUBE-2 de actieve LGW is die de registratie bijhoudt met Webex Calling-toegangs-SBC, terwijl de uitvoer van de 'show sip-ua register status' leeg is in VCUBE-1 |
3 |
Schakel nu de volgende foutopsporingen in op VCUBE-1
|
4 |
Simuleer failover door de volgende opdracht uit te voeren op de actieve LGW, in dit geval VCUBE-2.
Naast de hierboven vermelde CLI wordt er ook in het volgende scenario overgeschakeld van de ACTIEVE naar de STAND-BY-LGW
|
5 |
Controleer of VCUBE-1 is geregistreerd bij de Webex Calling-toegangs-SBC. VCUBE-2 moet nu opnieuw zijn geladen.
VCUBE-1 is nu de actieve LGW. |
6 |
Bekijk het relevante foutopsporingslogboek in VCUBE-1, waarin een SIP-registratie wordt verstuurd naar Webex Calling via het virtuele IP-adres en 200 OK wordt ontvangen. VCUBE-1#toon
|