- Kezdőlap
- /
- Cikk
A CUBE magas rendelkezésre állásának helyi átjáróként történő végrehajtása
A Helyi átjáró (LGW) az egyetlen lehetőség arra, hogy a Cisco Webex Calling ügyfelei számára telephelyalapú PSTN-elérés biztosítson. Ennek a dokumentumnak az a célja, hogy segítséget nyújtson a CUBE magas rendelkezésre állás, aktív vagy készenléti CUBE-k használatával a Helyi átjáró-konfiguráció felépítésében az aktív hívások állapotalapú feladatátvételéhez.
Alapok
Előfeltételek
Mielőtt a CUBE HA-t a Webex Calling helyi átjáró telepítené, győződjön meg arról, hogy alaposan ismeri a következő fogalmakat:
Layer 2 box-to-box redundancia a CUBE Enterprise segítségével az állapotalapú hívástartás
A jelen cikkben ismertetett konfigurációs irányelvek dedikált helyi átjáró feltételeznek, és nincs meglévő hangkonfiguráció. Ha egy meglévő CUBE vállalati telepítést úgy módosítanak, hogy a Cisco Webex Calling helyi átjáró funkcióját is használja, ügyeljen az alkalmazott konfigurációra, hogy a meglévő hívásfolyamatok és funkciók ne szakadjanak meg, és győződjön meg arról, hogy betartja a CUBE HA tervezési követelményeit .
Hardver és szoftver összetevők
A CUBE HA helyi átjáró az IOS-XE 16.12.2-es vagy újabb verzióját, valamint egy olyan platformot igényel, amelyen a CUBE HA és az LGW funkciók egyaránt támogatottak.
A cikkben szereplő show parancsok és naplók a Cisco IOS -XE 16.12.2 vCUBE-n (CSR1000v) megvalósított minimális szoftverkiadás alapulnak.
Referenciaanyag
Íme néhány részletes CUBE HA konfigurációs útmutató a különböző platformokhoz:
ISR 4K sorozat— 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
A Cisco által preferált Cisco Webex Calling architektúra — https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
A Webex Calling megoldás áttekintése
A Cisco Webex Calling egy olyan együttműködési ajánlat, amely több bérlős felhőalapú alternatívát kínál a helyszíni alközponti telefonos szolgáltatás , több PSTN opcióval az ügyfelek számára.
A cikk középpontjában a Helyi átjáró telepítése áll (lásd alább). A Webex Calling helyi átjáró (helyiség-alapú PSTN) törzse lehetővé teszi az ügyfél tulajdonában lévő PSTN-szolgáltatáshoz való kapcsolódást. Kapcsolódást biztosít egy helyszíni IP PBX-telepítéshez, például a Cisco Unified CM-hez. Minden, a felhő felé irányuló és onnan kiinduló kommunikáció a SIP esetében TLS , a média esetében pedig SRTP protokollal védett.
Az alábbi ábra egy meglévő IP PBX nélküli Webex Calling -telepítést mutat be, és egy vagy több telephelyes telepítésre vonatkozik. A cikkben ismertetett konfiguráció ezen a telepítésen alapul.
2. réteg Box-to-Box redundancia
A CUBE HA 2. réteg box-to-box redundancia a Redundancy Group (RG) infrastruktúra protokollt használja az aktív/készenléti útválasztó párt létrehozásához. Ez a pár ugyanazt a virtuális IP-cím (VIP) használja a megfelelő interfészeken, és folyamatosan állapotüzeneteket cserél. A CUBE-munkamenet-információk a két útválasztó között ellenőrzőpontokra kerülnek, így a készenléti útválasztó azonnal átveheti az összes CUBE hívásfeldolgozás feladatot, ha az aktív útválasztó kilép a szolgálatból, ami a jelzések és a média állapotmentes megőrzését eredményezi.
Az ellenőrző mutató csak a médiacsomaggal rendelkező kapcsolt hívásokra korlátozódik. A folyamatban lévő hívások nem ellenőrző pontok (például próbálkozás vagy csengő állapot).
Ebben a cikkben a CUBE HA a CUBE magas rendelkezésre állású (HA) Layer 2 Box-to-box (B2B) redundanciájára utal az állapotalapú hívástartás
Az IOS-XE 16.12.2 verziótól kezdődően a CUBE HA helyi átjáróként telepíthető a Cisco Webex Calling törzs (helyiség-alapú PSTN) telepítéseihez, és ebben a cikkben a tervezési szempontok és konfigurációkkal foglalkozunk. Az ábra egy tipikus CUBE HA-beállítást mutat be helyi átjáróként egy Cisco Webex Calling fővonali telepítéshez.
Redundanciacsoport infrakomponens
A redundanciacsoport (RG) Infra komponens biztosítja a dobozok közötti kommunikációs infrastruktúra támogatását a két CUBE között, és egyezteti a végleges stabil redundancia állapotot. Ez az összetevő a következőket is biztosítja:
Egy HSRP-szerű protokoll, amely a két CUBE közötti Keepalive és Hello üzenetek cseréjével egyezteti az egyes útválasztók végső redundancia állapotát – GigabitEthernet3 a fenti ábrán.
Egy átviteli mechanizmus a jelzések és a média állapotának ellenőrzésére minden egyes hívásnál az aktívtól a készenléti útválasztó felé (az adatinterfészen keresztül) – GigabitEthernet3 a fenti ábrán.
Virtuális IP (VIP) interfész konfigurálása és kezelése a forgalmi interfészekhez (több forgalmi interfész is konfigurálható ugyanazon RG-csoport használatával) – a GigabitEthernet 1 és 2 forgalmi interfésznek minősül.
Ezt az RG összetevőt kifejezetten a B2B HA hang támogatására kell beállítani.
Virtuális IP (VIP) címkezelés jelzésekhez és médiához egyaránt
A B2B HA a VIP-re támaszkodik a redundancia elérése érdekében. A CUBE HA párban lévő mindkét CUBE-n a VIP és a kapcsolódó fizikai interfészeknek ugyanazon a LAN-alhálózaton kell lenniük. A VIP konfigurálása és a VIP felületnek egy adott hangalkalmazáshoz (SIP) való hozzárendelése kötelező a hang B2B HA támogatásához. A külső eszközök, például a Unified CM, a Webex Calling hozzáférési SBC , a szolgáltató vagy a proxy a VIP célhelyszín IP-címe használják a CUBE HA útválasztókon áthaladó hívásoknál. Ezért a Webex Calling szempontjából a CUBE HA párok egyetlen helyi átjáró.
A létrehozott hívások hívásjelzési és RTP munkamenet-információi az aktív útválasztótól a készenléti útválasztó felé kerülnek ellenőrzési pontra. Amikor az aktív útválasztó leáll, a készenléti útválasztó veszi át az irányítást, és továbbítja azt az RTP-adatfolyam , amelyet korábban az első útválasztó továbbított.
A feladatátvétel időpontjában tranziens állapotban lévő hívások az átváltás után nem maradnak meg. Például olyan hívások, amelyek még nem teljesen beépültek, vagy módosításuk folyamatban van átvitel vagy tartás funkcióval. A létrehozott hívások az átkapcsolás után bonthatók.
A következő követelmények állnak fenn a CUBE HA helyi átjáró való használatához a hívások állapotalapú feladatátvételéhez:
A CUBE HA nem rendelkezhet egyidejűleg TDM vagy analóg interfészekkel
A Gig1 és Gig2 neve forgalmi (SIP/ RTP) interfész, a Gig3 pedig redundancia csoport (RG) vezérlő/adat interfész
Legfeljebb 2 CUBE HA pár helyezhető el ugyanabban a 2. rétegű tartományban, az egyik csoportazonosítója 1, a másik csoportazonosítója 2. Ha 2 HA párt állít be ugyanazzal a csoportazonosítóval, az RG Control/Data interfészeknek különböző 2. rétegbeli tartományokhoz kell tartozniuk (vlan, külön kapcsoló)
A portcsatorna az RG Vezérlő/adat és a forgalmi interfészeknél egyaránt támogatott
Minden jelzés/média a virtuális IP -címből származik/érkezik
Amikor egy platform újratöltődik CUBE-HA kapcsolatban, az mindig készenléti állapotban indul el
Az összes interfész (Gig1, Gig2, Gig3) alsó címének ugyanazon a platformon kell lennie
A redundancia interfész azonosítója, az rii egyedinek kell lennie az ugyanazon a 2. rétegen lévő pár/interfész kombináció esetén
A két CUBE konfigurációjának meg kell egyeznie a fizikai konfigurációval együtt, és ugyanazon a típusú platformon és az IOS-XE verzión kell futnia
A visszahurkolt felületek nem használhatók bind-ként, mivel mindig fent vannak
Több forgalmi (SIP/ RTP) interfész (Gig1, Gig2) esetén interfész nyomon követést kell konfigurálni
A CUBE-HA nem támogatott keresztkábeles kapcsolaton keresztül az RG-control/data kapcsolathoz (Gig3)
Mindkét platformnak ilyennek kell lennie azonos és a kapcsolaton keresztül a fizikai kapcsoló az összes hasonló interfészen ahhoz, hogy a CUBE HA működjön, azaz a CUBE-1 és a CUBE-2 GE0/0/0-jának ugyanazon a kapcsolón kell végződnie, és így tovább.
Közvetlenül a CUBE-kon nem végződhetett le a WAN, illetve egyik oldalon sem lehet HA-adat
Mindkét aktív/készenléti állapotnak ugyanabban az adatközpont kell lennie
A redundanciához külön L3 interfész használata kötelező (RG Control/data, Gig3). azaz a forgalomhoz használt felület nem használható HA életben tartáshoz és checkpointinghoz
Feladatátvételkor a korábban aktív CUBE tervezési újratöltésen esik át, megőrizve a jelzéseket és az adathordozókat
Redundancia konfigurálása mindkét CUBE-n
Konfigurálnia kell a 2. rétegű dobozok közötti redundanciát mindkét HA-párban használni kívánt CUBE-n a virtuális IP-címek előhívásához.
1 | Állítsa be az interfész nyomon követését globális szinten az interfész állapotának nyomon követéséhez.
A CLI nyomon követése az RG-ben a hangforgalom interfész állapotának nyomon követésére szolgál, így az aktív útvonal teljesen aktív szerepkört tölt be, miután a forgalmi interfész leállt. | ||
2 | Konfiguráljon egy RG-t a VoIP HA használatához az alkalmazásredundancia almódban.
Íme az ebben a konfigurációban használt mezők magyarázata:
| ||
3 | Box-to-box redundancia engedélyezése a CUBE alkalmazás számára. Konfigurálja az RG-t az előző lépésben a következőképpen:
redundancia-csoport 1 —A parancs hozzáadásához és eltávolításához újra be kell tölteni a frissített konfigurációt, hogy életbe lépjen. Az összes konfiguráció alkalmazása után újratöltjük a platformokat. | ||
4 | Konfigurálja a Gig1 és Gig2 felületeket a hozzájuk tartozó virtuális IP-címekkel az alábbiak szerint, és alkalmazza a redundancia interfész azonosítót ( rii )
Íme az ebben a konfigurációban használt mezők magyarázata:
| ||
5 | Mentse el az első CUBE konfigurációját, és töltse be újra. Az utolsóként betöltő platform mindig a Készenléti állapot.
Miután VCUBE-1 teljesen elindul, mentse a konfigurációját VCUBE-2 és töltse be újra.
| ||
6 | Ellenőrizze, hogy a fiókok közötti konfiguráció a várt módon működik-e. A megfelelő kimenet ki van jelölve a -ban félkövér . Újratöltöttük VCUBE-2 utolsó és a tervezési szempontok szerint; mindig az lesz a platform, amelyet utoljára kell újra betölteni Készenléti állapot .
|
Helyi átjáró konfigurálása mindkét CUBE-n
Példakonfigurációnkban a következő, a Control Hubból származó fővonal-információkat használjuk a helyi átjáró-konfiguráció felépítéséhez a VCUBE-1 és a VCUBE-2 platformokon. A beállításhoz tartozó felhasználónév és jelszó a következő:
Felhasználónév: Hussain1076_ LGU
Jelszó: lOV12MEaZx
1 | Gondoskodjon arról, hogy a jelszóhoz konfigurációs kulcsot hozzanak létre az alább látható parancsokkal, mielőtt azt a hitelesítő adatokban vagy a megosztott titkokban használni lehetne. A 6-os típusú jelszavak titkosítása AES titkosítással és ezzel a felhasználó által megadott konfigurációs kulccsal történik.
Itt van az a helyi átjáró-konfiguráció, amely mindkét platformra vonatkozik a fent megjelenített Control Hub-paraméterek alapján, mentés és újratöltés. A Control Hubból származó SIP kivonatolt azonosító adatok kiemelve jelennek meg félkövér .
A show parancs kimenetének megjelenítéséhez újratöltöttük VCUBE-2 követi VCUBE-1 , készítése VCUBE-1 a készenléti CUBE és VCUBE-2 az aktív KOCKÁT |
2 | Egy adott időpontban csak egy platform tart fenn aktív regisztrációt helyi átjáróként a Webex Calling hozzáférési SBC-vel. Vessen egy pillantást a következő show parancsok kimenetére. redundancia alkalmazáscsoport megjelenítése 1 Sip-ua regisztrációs állapot megjelenítése
A fenti kimenetből ez látható VCUBE-2 az aktív LGW, amely fenntartja a regisztrációt a Webex Calling access SBC-vel, miközben a „show sip-ua register status” kimenete üres VCUBE-1 |
3 | Most engedélyezze a következő hibakereséseket a VCUBE-1-en
|
4 | A feladatátvétel szimulálásához adja ki a következő parancsot az aktív LGW-n, ebben az esetben a VCUBE-2.
Az AKTÍV állapotról a KÉSZENLÉTI LGW-re való váltás a következő forgatókönyvben történik, valamint a fent felsorolt CLI-n kívül
|
5 | Ellenőrizze, hogy a VCUBE-1 regisztrálta-e a Webex Webex Calling access SBC-t. A VCUBE-2 már újratöltött volna.
A VCUBE-1 mostantól az aktív LGW. |
6 | Tekintse meg a VCUBE-1 vonatkozó hibakeresési naplóját: SIP REGISTER-t küld a Webex Calling a virtuális IP -n keresztül hívva és 200 OK-t kap.
|