- Etusivu
- /
- Artikkeli
Paikallinen yhdyskäytävä (LGW) on yksinomainen ratkaisu paikallisen PSTN-yhteyden tarjoamiseen Cisco Webex Calling -asiakkaille. Tämä asiakirja opastaa määrittämään paikallisen yhdyskäytävän käyttämällä CUBE-korkean käytettävyyden, aktiivisia tai valmiustilassa olevia CUBE:ita, jotta varmistetaan aktiivisten puheluiden tilallinen vikasietoisuus.
Perusteet
Edellytykset
Ennen kuin otat käyttöön Cisco Unified Border Element (CUBE) High Availability (HA) paikallisena yhdyskäytävänäWebex Calling, varmista, että ymmärrät perusteellisesti seuraavat käsitteet:
-
Layer 2 box-to-box-redundanssi CUBE Enterprise -sovelluksella puhelujen tilan säilyttämiseen
Tässä artikkelissa annetuissa määritysohjeissa oletetaan oma paikallinen yhdyskäytäväalusta, jolla ei ole olemassa olevaa äänikokoonpanoa. Jos olemassa olevaa CUBE-yrityskäyttöönottoa muokataan hyödyntämään myös paikallista yhdyskäytävätoimintoaCisco Webex Calling, kiinnitä erityistä huomiota sovellettuihin kokoonpanoihin varmistaaksesi, että olemassa olevat puheluvirrat ja toiminnot eivät keskeydy, ja varmista, että noudatat CUBE HA -suunnitteluvaatimuksia.
Laitteisto- ja ohjelmistokomponentit
CUBE HA paikallisena yhdyskäytävänä vaatii IOS-XE-version 17.9.1 tai uudemman ja alustan, jolla tuetaan sekä CUBE HA- että LGW-toimintoja.
Tämän artikkelin show-komennot ja lokit perustuvat Cisco IOS -XE 17.9.1 -ohjelmiston vähimmäisjulkaisuun, joka on toteutettu vCube (CSR 8000v) -laitteella.
Vertailumateriaali
Tässä on joitain yksityiskohtaisia CUBE HA -kokoonpano-oppaita eri alustoille:
-
Ciscon ensisijainen arkkitehtuuri Cisco Webex Calling - https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Webex CallingRatkaisun yleiskatsaus
Cisco Webex Callingon yhteistyötarjous, joka tarjoaa usean vuokralaisen pilvipohjaisen vaihtoehdon paikan päällä olevalle PBX-puhelinpalvelulle useilla PSTN-vaihtoehdoilla asiakkaille.
Paikallisen yhdyskäytävän käyttöönotto (esitetty alla) on tämän artikkelin painopiste. Paikallisen yhdyskäytä vän (tiloihin perustuva PSTN) runkoliitäntä mahdollistaa yhteyden asiakkaan omist Webex Calling amaan PSTN-palveluun. Se tarjoaa myös yhteyden paikalliseen IP PBX-käyttöönottoon, kuten. Cisco Unified CM Kaikki viestintä pilveen ja pilveen on suojattu TLS-siirrolla SIP: lle ja SRTP medialle.
Alla olevassa kuvassa näkyy Webex Calling käyttöönotto, jossa ei ole olemassa olevia IP-PBX:itä, ja sitä voidaan soveltaa yksittäiseen tai usean sivuston käyttöönottoon. Tässä artikkelissa kuvatut määritykset perustuvat tähän käyttöönottoon.
Kerros 2 laatikosta laatikkoon redundanssi
CUBE HA Layer 2 box-to-box redundanssi käyttää Redundancy Group (RG) -infrastruktuuriprotokollaa aktiivi-/valmiustilan reitittimien parin muodostamiseen. Tämä pari jakaa saman virtuaalisen IP-osoitteen (VIP) kunkin rajapinnan välillä ja vaihtaa jatkuvasti tilaviestejä. CUBE-istunnon tiedot tarkistetaan reitittimien parissa, jolloin valmiustilareititin voi ottaa kaikki CUBE-puheluiden käsittelyvastuut välittömästi, jos aktiivinen reititin poistuu käytöstä, mikä johtaa signaloinnin ja median tilan säilyttämiseen.
Tarkistus on rajoitettu mediapaketeilla varustettuihin kytkettyihin puheluihin. Siirrettävät puhelut eivät ole tarkistuskohdissa (esimerkiksi kokeilu- tai soittotila).
Tässä artikkelissa CUBE HA viittaa CUBE High Availability (HA) Layer 2 Box-to-Box (B2B) redundanssiin tilallisen puhelun säilyttämiseksi.
IOS-XE 17.9.1: sta lähtien CUBE HA voidaan ottaa käyttöön paikallisena yhdyskäytävänä Cisco Webex Calling runko-käyttöönotoissa (tiloihin perustuva PSTN). Tässä artikkelissa käsitellään suunnittelunäkökohtia ja kokoonpanoja. Kuvassa näkyy tyypillinen CUBE HA -asetus paikalliseksi yhdyskäytäväksi Cisco Webex Calling runko-käyttöönoton yhteydessä.
Redundanssiryhmän infrakomponentti
Redundancy Group (RG) Infra -komponentti tarjoaa laatikosta laatikkoon -viestintäinfrastruktuurin tuen kahden CUB:n välillä ja neuvottelee lopullisesta vakaasta redundanssitilasta. Tämä komponentti tarjoaa myös:
-
HSRP-tyyppinen protokolla, joka neuvottelee kunkin reitittimen lopullisen redundanssitilan vaihtamalla keepalive- ja hello-viestejä kahden CUBE: n välillä (ohjausrajapinnan kautta) —GigabiteThernet3 yllä olevassa kuvassa.
-
Kuljetusmekanismi signaloinnin ja median tilan tarkistamiseksi jokaiselle puhelulle aktiivisesta valmiustilaan reitittimestä (dataliittymän kautta) —GigabiteThernet3 yllä olevassa kuvassa.
-
Liikennerajapintojen Virtual IP (VIP) -rajapinnan kokoonpano ja hallinta (useita liikennelajapintoja voidaan konfiguroida käyttämällä samaa RG-ryhmää) - GigabitEthernet 1 ja 2 pidetään liikenteen rajapintoja.
Tämä RG-komponentti on konfiguroitava erityisesti tukemaan B2B HA -ääntä.
Virtuaalinen IP (VIP) -osoitteen hallinta sekä signaloinnille että medialle
B2B HA luottaa VIP: hen irtisanomisen saavuttamiseksi. CUBE HA -parin molempien CUBE:n VIP- ja siihen liittyvien fyysisten rajapintojen on sijaittava samassa LAN-aliverkossa. VIP: n konfigurointi ja VIP-käyttöliittymän sitominen tiettyyn äänisovellukseen (SIP) ovat pakollisia puheen B2B HA -tuelle. Ulkoiset laitteetUnified CM, kuten SB Webex Calling C, palveluntarjoaja tai välityspalvelin, käyttävät VIP: tä kohde-IP-osoitteena CUBE HA -reitittimien kautta kulkeville puheluille. Siksi CUBE HA Webex Calling -parit toimivat näkökulmasta yhtenä paikallisena yhdyskäytävänä.
Vakiintuneiden puheluiden puhelun signalointi ja RTP-istunnon tiedot tarkistetaan aktiivisesta reitittimestä valmiustilaan. Kun aktiivinen reititin kaatuu, Standby-reititin ottaa vallan ja jatkaa ensimmäisen reitittimen aiemmin reitittämän RTP-virran siirtämistä eteenpäin.
Puheluita, jotka ovat väliaikaisessa tilassa vikasietoisen siirron aikana, ei säilytetä siirtymisen jälkeen. Esimerkiksi puhelut, joita ei ole vielä täysin perustettu tai joita muokataan siirto- tai pidätystoiminnolla. Vakiintuneet puhelut voidaan katkaista siirtymisen jälkeen.
Seuraavat vaatimukset ovat voimassa CUBE HA:n käyttämiselle paikallisena yhdyskäytävänä puheluiden tilavalvontaa varten:
-
CUBE HA: lla ei voi olla TDM- tai analogisia rajapintoja
-
Gig1 ja Gig2 kutsutaan liikenteen (SIP/RTP) rajapinnoiksi ja Gig3 on redundanssiryhmän (RG) ohjaus/dataliitäntä
-
Samaan kerroksen 2 domeeniin voidaan sijoittaa enintään 2 CUBE HA -paria, joista toisella on ryhmän tunnus 1 ja toisella ryhmän tunnus 2. Jos määrität 2 HA-paria samalla ryhmätunnuksella, RG Control/Data -rajapintojen on kuuluttava eri tason 2 verkkotunnuksiin (vlan, erillinen kytkin)
-
Porttikanavaa tuetaan sekä RG-ohjauksen/data- että liikenteen rajapinnoissa
-
Kaikki signaali/media hankitaan virtuaalisesta IP-osoitteesta/siihen
-
Aina kun alusta ladataan uudelleen CUBE-HA-suhteessa, se käynnistyy aina valmiustilassa
-
Kaikkien rajapintojen (Gig1, Gig2, Gig3) alemman osoitteen tulisi olla samalla alustalla
-
Redundanssirajapinnan tunnisteen, rii tulisi olla ainutlaatuinen pari-/liitäntäyhdistelmälle samassa kerroksessa 2
-
Molempien CUBE-laitteiden kokoonpanon on oltava identtinen, mukaan lukien fyysinen kokoonpano, ja niiden on oltava käynnissä samantyyppisellä alustalla ja IOS-XE-versiolla
-
Loopback-rajapintoja ei voida käyttää sidona, koska ne ovat aina päällä
-
Usean liikenteen (SIP/RTP) rajapinnat (Gig1, Gig2) edellyttävät käyttöliittymän seurannan määrittämistä
-
CUBE-HA:ta ei tueta RG-ohjaus/datalinkin (Gig3) ristikaapeliliitännän kautta
-
Molempien alustojen on oltava identtisiä ja kytkettävä fyysisen kytkim en kautta kaikkiin vastaaviin rajapintoihin, jotta CUBE HA toimisi, ts. CUBE-1: n ja CUBE-2: n GE0/0/0: n on päätettävä samalla kytkimellä ja niin edelleen.
-
WAN-verkkoa ei voida lopettaa suoraan CUBE:ssa tai Data HA: lla kummallakin puolella
-
Sekä aktiivisen että valmiustilan on oltava samassa datakeskuksessa
-
Redundanssiin on pakko käyttää erillistä L3-liitäntää (RG Control/data, Gig3). ts. liikenteessä käytettävää rajapintaa ei voida käyttää HA-tallennusvälineisiin ja tarkistuspisteisiin
-
Virheensiirron yhteydessä aiemmin aktiivinen CUBE käy läpi suunnittelun mukaisen uudelleenlatauksen säilyttäen signaloinnin ja tietovälineen
Määritä redundanssi molemmissa CUBEissa
Sinun on määritettävä kerroksen 2 laatikosta laatikkoon redundanssi molemmissa CUBE:issa, jotka on tarkoitettu käytettäväksi HA-parissa virtuaalisten IP-osoitteiden tuomiseksi.
| 1 |
Määritä käyttöliittymän seuranta globaalilla tasolla seurataksesi käyttöliittymän tilaa.
Track CLI: tä käytetään RG:ssä ääniliikenteen rajapinnan tilan seuraamiseen siten, että aktiivinen reitti saa melko aktiivisen roolinsa liikenteen rajapinnan ollessa poissa käytöstä. | ||
| 2 |
Määritä RG käytettäväksi VoIP HA: n kanssa sovelluksen redundanssin alitilassa.
Tässä on selitys tässä kokoonpanossa käytetyistä kentistä:
| ||
| 3 |
Ota käyttöön laatikosta laatikkoon redundanssi CUBE-sovelluksessa. Määritä RG edellisestä vaiheesta alla
redundancy-group 1 — Tämän komennon lisääminen ja poistaminen vaatii uudelleenlatauksen, jotta päivitetty kokoonpano tulee voimaan. Lataamme alustat uudelleen, kun kaikki kokoonpanot on otettu käyttöön. | ||
| 4 |
Määritä Gig1- ja Gig2-rajapinnat vastaavilla virtuaalisilla IP-osoitteilla alla olevan kuvan mukaisesti ja käytä redundanssirajapinnan tunnistetta (rii)
Tässä on selitys tässä kokoonpanossa käytetyistä kentistä:
| ||
| 5 |
Tallenna ensimmäisen CUBE: n kokoonpano ja lataa se uudelleen. Viimeisenä ladattava alusta on aina valmiustila.
Kun VCUBE-1 käynnistyy kokonaan, tallenna V CUBE-2: n kokoonpano ja lataa se uudelleen.
| ||
| 6 |
Varmista, että laatikosta laatikkoon -määritys toimii odotetulla tavalla. Asiaankuuluva tuotos on korostettu li havoit una. Latasimme VCUBE-2: n viimeksi ja suunnittelunäkökohtien mukaan; viimeisenä ladattava alusta on aina valmiustila.
Seuraavaksi jatka paikallisen yhdyskäytävän kokoonpanoa (rekisteröinti- tai varmentepohjainen ) molemmissa HA CUBE:issa. Katso Paikallisen yhdyskäytävän määrittäminen Cisco IOS XE: ssä Webex Calling. |