- Pagină de pornire
- /
- Articol
Local Gateway (LGW) este soluția exclusivă pentru furnizarea accesului PSTN local clienților Cisco Webex Calling. Acest document vă ghidează în configurarea unui gateway local utilizând CUBE de înaltă disponibilitate, cu CUBE active sau de așteptare pentru a asigura failover-ul de stare al apelurilor active.
Fundamente
Cerințe preliminare
Înainte de a implementa Cisco Unified Border Element (CUBE) High Availability (HA) ca gateway local pentruWebex Calling, asigurați-vă că aveți o înțelegere aprofundată a următoarelor concepte:
-
Redundanță de nivel 2 box-to-box cu CUBE Enterprise pentru păstrarea stării apelurilor
Instrucțiunile de configurare furnizate în acest articol presupun o platformă dedicată de gateway local fără configurație vocală existentă. Dacă o implementare corporativă CUBE existentă este modificată pentru a utiliza și funcția gateway local pentruCisco Webex Calling, acordați o atenție deosebită configurației aplicate pentru a vă asigura că fluxurile de apeluri și funcționalitățile existente nu sunt întrerupte și asigurați-vă că respectați cerințele de proiectare CUBE HA.
Componente hardware și software
CUBE HA ca gateway local necesită versiunea IOS-XE 17.9.1 sau o versiune ulterioară și o platformă pe care sunt acceptate atât funcțiile CUBE HA, cât și LGW.
Comenzile de prezentare și jurnalele din acest articol se bazează pe versiunea minimă de software a Cisco IOS -XE 17.9.1 implementată pe un vCube (CSR 8000v).
Material de referință
Iată câteva ghiduri detaliate de configurare CUBE HA pentru diverse platforme:
-
Arhitectura preferată Cisco pentru Cisco Webex Calling - https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Webex CallingPrezentare generală a soluției
Cisco Webex Callingeste o ofertă de colaborare care oferă o alternativă bazată pe cloud cu mai mulți chiriași la serviciul de telefonie PBX on-premise, cu mai multe opțiuni PSTN pentru clienți.
Implementarea gateway-ului local (reprezentată mai jos) este punctul central al acestui articol. Trunchiul gateway local (PSTN bazat pe premise) Webex Calling permite conectivitatea la un serviciu PSTN deținut de client. De asemenea, oferă conectivitate la o implementare IP PBX locală, cum ar fi. Cisco Unified CM Toate comunicațiile către și dinspre cloud sunt securizate folosind transportul TLS pentru SIP și SRTP pentru media.
Figura de mai jos afișează o Webex Calling implementare fără niciun PBX IP existent și se aplică unei implementări unice sau cu mai multe site-uri. Configurația prezentată în acest articol se bazează pe această implementare.
Redundanță de la cutie la cutie de nivel 2
Redundanța cube HA layer 2 box-to-box utilizează protocolul de infrastructură Redundancy Group (RG) pentru a forma o pereche de routere activă/standby. Această pereche partajează aceeași adresă IP virtuală (VIP) în interfețele respective și schimbă continuu mesaje de stare. Informațiile despre sesiunea CUBE sunt verificate pe perechea de routere, permițând routerului standby să preia imediat toate responsabilitățile de procesare a apelurilor CUBE dacă routerul activ iese din funcțiune, ceea ce duce la păstrarea stării de stare a semnalării și a mediilor media.
Indicarea verificării este limitată la apelurile conectate cu pachete media. Apelurile aflate în tranzit nu sunt indicate (de exemplu, o stare de încercare sau de apel).
În acest articol, CUBE HA se va referi la redundanța Cube High Availability (HA) Layer 2 Box-to-Box (B2B) pentru păstrarea apelurilor de stare.
Începând cu IOS-XE 17.9.1, CUBE HA poate fi implementat ca un gateway local pentru implementări Cisco Webex Calling trunchi (PSTN bazat pe premise). Acest articol va discuta considerente de proiectare și configurații. Figura afișează o configurare tipică CUBE HA ca gateway local pentru o implementare Cisco Webex Calling trunchiului.
Componenta infra a grupului de redundanță
Componenta Infra Redundancy Group (RG) asigură suportul infrastructurii de comunicații box-to-box între cele două CUBE și negociază starea finală de redundanță stabilă. Această componentă oferă, de asemenea:
-
Un protocol asemănător HSRP care negociază starea finală de redundanță pentru fiecare router prin schimbul de mesaje keepalive și hello între cele două CUBE (prin interfața de control) —GigabiteThernet3 în figura de mai sus.
-
Un mecanism de transport pentru verificarea semnalizării și a stării media pentru fiecare apel de la routerul activ la routerul de așteptare (prin interfața de date) —GigabiteThernet3 în figura de mai sus.
-
Configurarea și gestionarea interfeței IP virtuale (VIP) pentru interfețele de trafic (mai multe interfețe de trafic pot fi configurate folosind același grup RG) - GigabitEthernet 1 și 2 sunt considerate interfețe de trafic.
Această componentă RG trebuie configurată special pentru a sprijini vocea B2B HA.
Gestionarea adresei IP virtuale (VIP) atât pentru semnalizare, cât și pentru media
B2B HA se bazează pe VIP pentru a obține redundanță. Interfețele fizice VIP și asociate de pe ambele CUBE din perechea CUBE HA trebuie să se afle pe aceeași subrețea LAN. Configurarea VIP și legarea interfeței VIP la o anumită aplicație vocală (SIP) sunt obligatorii pentru suportul vocal B2B HA. Dispozitivele externeUnified CM, cum ar fi, Webex Calling acces SBC, furnizor de servicii sau proxy, utilizează VIP ca adresă IP de destinație pentru apelurile care traversează routerele CUBE HA. Prin urmare, din Webex Calling punct de vedere, perechile CUBE HA acționează ca un singur gateway local.
Semnalizarea apelurilor și informațiile despre sesiunea RTP ale apelurilor stabilite sunt verificate de la routerul activ la routerul de așteptare. Când routerul activ se oprește, routerul Standby preia controlul și continuă să transmită fluxul RTP care a fost direcționat anterior de primul router.
Apelurile aflate într-o stare tranzitorie în momentul failover nu vor fi păstrate după comutare. De exemplu, apelurile care nu sunt încă pe deplin stabilite sau sunt în curs de modificare cu o funcție de transfer sau reținere. Apelurile stabilite pot fi deconectate după comutare.
Există următoarele cerințe pentru utilizarea CUBE HA ca gateway local pentru failover-ul de stare a apelurilor:
-
CUBE HA nu poate avea interfețe TDM sau analogice co-localizate
-
Gig1 și Gig2 sunt denumite interfețe de trafic (SIP/RTP), iar Gig3 este interfață de control/date a grupului de redundanță (RG)
-
Nu mai mult de 2 perechi CUBE HA pot fi plasate în același domeniu strat 2, una cu identificatorul grupului 1 și cealaltă cu grupul id 2. Dacă configurați 2 perechi HA cu același id de grup, interfețele RG Control/Data trebuie să aparțină diferitelor domenii de nivel 2 (vlan, comutator separat)
-
Canalul de port este acceptat atât pentru interfețele de control RG/date, cât și pentru trafic
-
Toate semnalule/mediile sunt furnizate de la/la adresa IP virtuală
-
Ori de câte ori o platformă este reîncărcată într-o relație CUBE-HA, aceasta pornește întotdeauna ca Standby
-
Adresa inferioară pentru toate interfețele (Gig1, Gig2, Gig3) ar trebui să fie pe aceeași platformă
-
Identificatorul interfeței de redundanță, rii ar trebui să fie unic pentru o combinație perechi/interfață pe același strat 2
-
Configurația pe ambele CUBE trebuie să fie identică, inclusiv configurația fizică și trebuie să ruleze pe același tip de platformă și versiunea IOS-XE
-
Interfețele Loopback nu pot fi utilizate ca bind, deoarece sunt întotdeauna în funcțiune
-
Interfețele de trafic multiplu (SIP/RTP) (Gig1, Gig2) necesită configurarea urmăririi interfeței
-
CUBE-HA nu este acceptat printr-o conexiune prin cablu încrucișat pentru legătura RG-Control/Data Link (Gig3)
-
Ambele platforme trebuie să fie identice și să fie conectate printr-un comutator fizic pe toate interfețele similare pentru ca CUBE HA să funcționeze, adică GE0/0/0 din CUBE-1 și CUBE-2 trebuie să se termine pe același comutator și așa mai departe.
-
Nu se poate termina WAN direct pe CUBE-uri sau Data HA pe ambele părți
-
Ambele active/Standby trebuie să fie în același centru de date
-
Este obligatorie utilizarea unei interfețe L3 separate pentru redundanță (Control/date RG, Gig3). adică interfața utilizată pentru trafic nu poate fi utilizată pentru păstrarea HA și pentru punctajul de control
-
La failover, CUBE activ anterior trece printr-o reîncărcare prin proiectare, păstrând semnalizarea și mediile
Configurați redundanța pe ambele CUBE
Trebuie să configurați redundanța box-to-box layer 2 pe ambele CUBE destinate a fi utilizate într-o pereche HA pentru a afișa IP-uri virtuale.
| 1 |
Configurați urmărirea interfeței la nivel global pentru a urmări starea interfeței.
Track CLI este utilizat în RG pentru a urmări starea interfeței traficului vocal, astfel încât ruta activă își va avea rolul activ după ce interfața de trafic este întreruptă. | ||
| 2 |
Configurați un RG pentru utilizare cu VoIP HA în sub-modul redundanță a aplicației.
Iată o explicație a câmpurilor utilizate în această configurație:
| ||
| 3 |
Activați redundanța box-to-box pentru aplicația CUBE. Configurați RG-ul de la pasul anterior de mai jos.
redundancy-group 1 —Adăugarea și eliminarea acestei comenzi necesită o reîncărcare pentru ca configurația actualizată să intre în vigoare. Vom reîncărca platformele după ce a fost aplicată toată configurația. | ||
| 4 |
Configurați interfețele Gig1 și Gig2 cu IP-urile virtuale respective, așa cum se arată mai jos și aplicați identificatorul interfeței de redundanță (rii)
Iată o explicație a câmpurilor utilizate în această configurație:
| ||
| 5 |
Salvați configurația primului CUB și reîncărcați-l. Platforma pentru a reîncărca ultima dată este întotdeauna Standby.
După ce VCUBE-1 pornește complet, salvați configurația VCU BE-2 și reîncărcați-o.
| ||
| 6 |
Verificați dacă configurația box-to-box funcționează conform așteptărilor. Rezultatul relevant este evidențiat cu caractere aldine. Am reîncărcat VCUBE-2 ultima dată și conform considerațiilor de proiectare; platforma de reîncărcare ultima va fi întotdeauna Standby.
Apoi, continuați cu configurația Local Gateway (bazată pe înregistrare sau pe bază de certificat) pe ambele CUBE HA. Consultați Configurarea gateway-ului local pe Cisco IOS XE pentru Webex Calling. |