- Kezdőlap
- /
- Cikk
A CUBE magas elérhetőségének megvalósítása helyi átjáróként
A Helyi átjáró (LGW) az exkluzív megoldás a helyszíni PSTN-hozzáférés biztosításához a Cisco Webex Calling ügyfelek számára. Ez a dokumentum bemutatja, hogyan konfigurálhat egy helyi átjárót magas rendelkezésre állású CUBE használatával, aktív vagy készenléti CUBE-kkal, hogy biztosítsa az aktív hívások statikus feladatátvételét.
Alapvető tudnivalók
Előfeltételek
Mielőtt a Cisco Unified Border Element (CUBE) High Availability (HA) szolgáltatást helyi átjáróként telepíti a Webex Calling alkalmazáshoz, győződjön meg arról, hogy alaposan megértette a következő fogalmakat:
-
2. réteg dobozonként redundancia a CUBE Enterprise segítségével a stabil hívásmegőrzés érdekében
Az ebben a cikkben megadott konfigurációs iránymutatások egy dedikált helyi átjáróplatformot feltételeznek, meglévő hangkonfiguráció nélkül. Ha egy meglévő CUBE vállalati üzembe helyezése úgy módosul, hogy a Cisco Webex Calling helyi átjáró funkcióját is használja, fordítson nagy figyelmet az alkalmazott konfigurációra, hogy a meglévő hívásfolyamok és funkciók ne szakadjanak meg, és ügyeljen arra, hogy betartsa a CUBE HA tervezési követelményeit.
Hardver és szoftver komponensek
A CUBE HA helyi átjáróhoz 17.9.1-es vagy újabb IOS-XE verzióra és egy olyan platformra van szükség, amelyen mind a CUBE HA, mind az LGW funkciók támogatottak.
Az ebben a cikkben található megjelenítési parancsok és naplók a Cisco IOS-XE 17.9.1 minimális szoftverkiadásán alapulnak, amelyet vCUBE (CSR 8000v) használatával hajtanak végre.
Referenciaanyag
Íme néhány részletes CUBE HA konfigurációs útmutató a különböző platformokhoz:
-
Cisco ISR 4K és Cisco Catalyst 8K sorozat – https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m-cube-ha-isr-g3.html
-
CSR 8000v (vCUBE)— https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m-cube-ha-csr.html
-
A Cisco által előnyben részesített architektúra a Cisco Webex Calling alkalmazáshoz – 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üttműködési ajánlat, amely több bérlős, felhőalapú alternatívát kínál a helyhez kötött PBX-telefonszolgáltatással szemben, több PSTN-beállítással az ügyfelek számára.
Ennek a cikknek a középpontjában a Helyi átjáró telepítése áll (alább látható). A Webex Calling helyi átjáró (telephelyalapú PSTN) fővonala lehetővé teszi az ügyfél tulajdonában lévő PSTN-szolgáltatáshoz való csatlakozást. Kapcsolatot biztosít egy helyszíni IP PBX telepítéshez is, például a Cisco Unified CM-hez. A felhőbe irányuló és a felhőből érkező kommunikáció SIP-hez és SRTP-hez TLS-átvitellel van biztosítva.
Az alábbi ábra egy meglévő IP PBX nélküli Webex Calling-telepítést jelenít meg, és egyetlen vagy több helyszínen történő telepítésre alkalmazható. Az ebben a cikkben körvonalazott konfiguráció ezen a telepítésen alapul.
2. réteg dobozok közötti redundancia
A CUBE HA 2. réteg dobozok közötti redundancia a Redundancia Group (RG) infrastruktúra protokollját használja aktív/készenléti routerek párosításához. Ennek a párnak ugyanaz a virtuális IP-címe (VIP) van a saját felületén, és folyamatosan kicseréli az állapotüzeneteket. A CUBE munkamenet információi a routerek párjára mutatnak, lehetővé téve a készenléti router számára, hogy azonnal átvegye az összes CUBE hívásfeldolgozási felelősséget, ha az aktív router szolgáltatás leáll, ami a jelátvitel és a média megfelelő megőrzését eredményezi.
Az ellenőrzési mutató a médiacsomagokkal összekapcsolt hívásokra korlátozódik. A tranzithívások nem jelennek meg (például próbáló vagy kicsengő állapot).
Ebben a cikkben a CUBE HA a CUBE High Availability (HA) Layer 2 Box-to-Box (B2B) redundanciára utal az államszerű hívásmegőrzés érdekében.
Az IOS-XE 17.9.1-ES VERZIÓJÁTÓL A CUBE HA helyi átjáróként telepíthető a Cisco Webex Calling trönktelepítései számára (telephelyalapú PSTN). Ez a cikk a tervezési szempontokat és a konfigurációkat tárgyalja. Az ábrán egy tipikus CUBE HA-beállítás jelenik meg helyi átjáróként a Cisco Webex Calling trönk telepítéséhez.
Redundanciacsoport infravörös komponens
A redundancia csoport (RG) infra komponens biztosítja a két CUBE közötti box-to-box kommunikációs infrastruktúra támogatását, és tárgyalja a végleges stabil redundancia állapotot. Ez az összetevő a következőket is biztosítja:
-
Egy HSRP-szerű protokoll, amely az egyes routerek végső redundancia állapotát tárgyalja élő és üdvözlő üzenetek cseréjével a két CUBE között (a vezérlőfelületen keresztül) – GigabitEthernet3 a fenti ábrán.
-
Átviteli mechanizmus az aktív és a készenléti útválasztó között (az adatinterfészen keresztül) minden egyes hívás jelzésjelzésének és médiaállapotának ellenőrzéséhez – GigabitEthernet3 a fenti ábrán.
-
Konfiguráció és kezelése a virtuális IP (VIP) interfész a forgalom interfészek (több forgalom interfész is konfigurálható ugyanazon RG csoport) – GigabitEthernet 1. és 2. közlekedési interfésznek minősül.
Ezt az RG-összetevőt kifejezetten úgy kell konfigurálni, hogy támogassa a hang B2B HA-t.
Virtuális IP (VIP) cím kezelése mind jelzésszolgáltatáshoz, mind médiához
A B2B HA VIP-re támaszkodik a redundancia elérése érdekében. A CUBE HA párt mindkét CUBE-ján lévő VIP és kapcsolódó fizikai interfészeknek ugyanazon a LAN alhálózaton kell lenniük. A VIP konfigurálása és a VIP felület kötése egy adott hangalkalmazáshoz (SIP) kötelező a voice B2B HA támogatásához. A külső eszközök, mint például a Unified CM, a Webex Calling-hozzáférés SBC, a szolgáltató vagy a proxy a VIP protokollt használják cél IP-címként a CUBE HA-routereken áthaladó hívásokhoz. Ezért a Webex Calling szempontjából a CUBE HA-pár egyetlen helyi átjáróként működik.
A létrehozott hívások hívásjelzési és RTP munkamenet információi az aktív útválasztóról a készenléti útválasztóra mutatnak. Amikor az aktív útválasztó leáll, a készenléti útválasztó átveszi, és folytatja a korábban az első útválasztó által irányított RTP adatfolyamot.
A feladatátvételkor átmeneti állapotban lévő hívások nem maradnak meg az átváltás után. Például olyan hívások, amelyeket még nem hoztak létre teljesen, vagy amelyek módosítása folyamatban van egy átadás vagy tartás funkcióval. Előfordulhat, hogy a létrehozott hívások kapcsolata az átváltás után megszakad.
A következő követelmények érvényesek a CUBE HA helyi átjáróként való használatára a hívások statikus feladatátvételéhez:
-
A CUBE HA nem rendelkezhet TDM vagy analóg interfészekkel együtt
-
A Gig1-et és a Gig2-t forgalmi (SIP/RTP) interfészeknek nevezik, a Gig3 pedig redundanciacsoport (RG) vezérlő/adatinterfész
-
Legfeljebb 2 CUBE HA-pár helyezhető el ugyanazon a 2. réteg tartományon, egyet csoportazonosítóval 1 és a másik a 2. csoportazonosítóval. Ha 2 HA-párt konfigurál ugyanazzal a csoportazonosítóval, akkor az RG Control/Data interfészeknek különböző 2. réteg tartományokhoz kell tartozniuk (vlan, külön kapcsoló)
-
A portcsatorna az RG-vezérlő/adat- és a forgalmi interfészeken egyaránt támogatott
-
Minden jelzésátvitel/média a virtuális IP-címről/címre származik
-
Amikor egy platform újratöltődik egy CUBE-HA kapcsolatban, mindig készenléti állapotként indul el
-
Az összes interfész (Gig1, Gig2, Gig3) alacsonyabb címének ugyanazon a platformon kell lennie
-
Redundancia interfész azonosító, a rii-nek egyedinek kell lennie ugyanazon a 2. rétegen lévő pár/interfész kombinációra
-
A konfigurációnak mindkét CUBE-on azonosnak kell lennie, beleértve a fizikai konfigurációt is, és ugyanazon a platformtípuson és IOS-XE verzión kell futnia
-
A loopback-interfészek nem használhatók annyira kötve, mivel mindig fel vannak emelve
-
A több forgalom (SIP/RTP) interfészének (Gig1, Gig2) konfigurálni kell az interfész követését
-
A CUBE-HA nem támogatott az RG-vezérlő/adatkapcsolat (Gig3) keresztkötéses kábelkapcsolaton keresztül
-
Mindkét platformnak azonosnak kell lennie, és a CUBE HA működéséhez egy fizikai kapcsolón keresztül kell kapcsolódnia minden hasonló felületen, azaz a CUBE-1 és a CUBE-2 GE0/0/0 gombjának ugyanazon a kapcsolón kell véget érnie stb.
-
Nem lehet, hogy a WAN közvetlenül a CUBE-n, illetve egyik oldalon sem fejeződött be a Data HA
-
Mindkét aktív/készenléti állapotnak ugyanabban az adatközpontban kell lennie
-
Kötelező külön L3 interfészt használni a redundancia érdekében (RG Control/data, Gig3). azaz a forgalomhoz használt interfész nem használható a HA életben tartásához és ellenőrzőmutatásához.
-
Feladatátvétel esetén a korábban aktív CUBE újratöltésen megy keresztül, megőrizve a jelátvitelt és a médiát
Redundancia konfigurálása mindkét CUBE-on
A 2. réteg dobozonként redundanciát konfigurálnia kell mindkét olyan CUBE-on, amelyet egy HA-párban szeretne használni virtuális IP-k létrehozásához.
1 |
Konfigurálja az interfész nyomon követését globális szinten az interfész állapotának nyomon követéséhez.
A CLI követése az RG-ben a hangforgalmi interfész állapotának nyomon követésére szolgál, így az aktív útvonal teljesen aktív szerepet kap, miután a forgalmi interfész leállt. | ||
2 |
Konfiguráljon egy RG-t a VoIP HA-val való használatra az alkalmazás redundancia alüzemmódban.
Az ebben a konfigurációban használt mezők magyarázata:
| ||
3 |
Engedélyezze a dobozok közötti redundanciát a CUBE alkalmazáshoz. Konfigurálja az RG-t a(z)
1. redundancia-csoport – A parancs hozzáadása és eltávolítása újratöltése szükséges ahhoz, hogy a frissített konfiguráció életbe lépjen. Az összes konfiguráció alkalmazása után újratöltjük a platformokat. | ||
4 |
Konfigurálja a Gig1 és Gig2 felületet a megfelelő virtuális IP-címekkel az alábbiak szerint, és alkalmazza a redundancia interfész azonosítót (rii)
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 újratöltendő platform mindig a készenléti állapot.
Miután a VCUBE-1 teljesen elindul, mentse a VCUBE-2 konfigurációját, majd töltse be újra.
| ||
6 |
Ellenőrizze, hogy a dobozok közötti konfiguráció megfelelően működik-e. A releváns kimenet félkövér betűkkel van kiemelve. Utoljára újratöltöttük a VCUBE-2 -t, a tervezési szempontoknak megfelelően; az újratöltendő platform mindig készenléti lesz. Ezután folytassa a helyi átjáró konfigurációját (regisztrációalapú vagy tanúsítványalapú) mindkét HA CUBE-n. Lásd: Helyi átjáró konfigurálása a Cisco IOS XE-ben a Webex Callinghoz. |