- Kezdőlap
- /
- Cikk
A Local Gateway (LGW) az exkluzív megoldás a helyszíni PSTN-hozzáférés biztosítására a Cisco Webex Calling ügyfelek számára. Ez a dokumentum útmutatást nyújt Önnek a helyi átjáró konfigurálásához a CUBE magas rendelkezésre állással, aktív vagy készenléti CUBES használatával, hogy biztosítsa az aktív hívások állapotú feladatátvitelét.
Alapvető
Feltételek
Mielőtt a Cisco Unified Border Element (CUBE) High Availability (HA) helyi átjáróként telepítenéWebex Calling, győződjön meg róla, hogy alaposan megértette a következő fogalmakat:
-
2. rétegű box-to-box redundancia a CUBE Enterprise segítségével a hívások állapotos megőrzéséhez
Az ebben a cikkben megadott konfigurációs irányelvek egy dedikált helyi átjáró platformot feltételezik, amelynek nincs meglévő hangkonfigurációja. Ha egy meglévő CUBE vállalati telepítést úgy módosítják, hogy a helyi átjáró funkciót is használhassaCisco Webex Calling, figyeljen az alkalmazott konfigurációra annak biztosítására, hogy a meglévő hívásfolyamatok és funkciók ne szakadjanak meg, és győződjön meg róla, hogy betartja a CUBE HA tervezési követelményeit.
Hardver- és szoftverkomponensek
A CUBE HA helyi átjáróként az IOS-XE 17.9.1 vagy újabb verziót igényel, valamint egy olyan platformot, amelyen mind a CUBE HA, mind az LGW funkciók támogatottak.
Az ebben a cikkben szereplő megjelenítési parancsok és naplók a Cisco IOS -XE 17.9.1 minimális szoftverkiadásán alapulnak, amely egy vCube-on (CSR 8000v) van megvalósítva.
Referenciaanyag
Íme néhány részletes CUBE HA konfigurációs útmutató különböző platformokhoz:
-
A Cisco preferált architektúrá Cisco Webex Calling ja - https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Webex CallingMegoldás áttekintése
Cisco Webex Callingegy együttműködési ajánlat, amely több bérlő felhőalapú alternatívát kínál a helyszíni PBX telefonszolgáltatáshoz, több PSTN-opcióval az ügyfelek számára.
A helyi átjáró telepítése (alább ábrázolva) áll a cikk középpontjában. A helyi átjáró (helyiségalapú PSTN) törzs Webex Calling lehetővé teszi az ügyfél tulajdonában lévő PSTN szolgáltatáshoz való csatlakozást. Csatlakozást biztosít egy helyszíni IP PBX telepítéshez is, mint például. Cisco Unified CM A felhőbe érkező és onnan érkező kommunikáció TLS transzport segítségével biztosított a SIP-hez és az SRTP médiához.
Az alábbi ábra egy meglévő IP-PBX nélküli Webex Calling telepítést jelenít meg, és egy vagy több helyszíni telepítésre alkalmazható. A cikkben ismertetett konfiguráció ezen a telepítésen alapul.
2. réteg doboz-dobozos redundanciája
A CUBE HA 2. réteg box-to-box redundanciája a Redundancy Group (RG) infrastruktúra protokollt használja egy aktív/készenléti útválasztó pár létrehozásához. Ez a pár ugyanazt a virtuális IP-címet (VIP) osztja meg a megfelelő interfészükön, és folyamatosan cserél állapotüzeneteket. A CUBE munkamenet információit a routerek párján ellenőrzik, így a készenléti router azonnal átvállalja az összes CUBE hívásfeldolgozási feladatot, ha az aktív router nem működik, ami a jelzés és a média állapotban megőrzését eredményezi.
Az ellenőrző mutatás csak a médiacsomagokkal csatlakoztatott hívásokra korlátozódik. Az átviteli hívások nem jelölőnégyzetesek (például próbálkozási vagy csengő állapot).
Ebben a cikkben a CUBE HA hivatkozik a CUBE High Availability (HA) Layer 2 Box-to-Box (B2B) redundanciára a hívások állapotos megőrzéséhez.
Az IOS-XE 17.9.1-től kezdve a CUBE HA helyi átjáróként telepíthető a törzs telepítésekhez (helyiségal Cisco Webex Calling apú PSTN). Ez a cikk a tervezési szempontokat és konfigurációkat tárgyalja. Az ábra egy tipikus CUBE HA beállítást jelenít meg helyi átjáróként a Cisco Webex Calling törzs telepítéshez.
Redundanciacsoport infra komponens
A Redundancy Group (RG) Infra komponens biztosítja a box-to-box kommunikációs infrastruktúra támogatását a két CUBE között, és tárgyalja a végső stabil redundanciaállapotot. Ez az összetevő a következőket is tartalmazza:
-
HSRP-szerű protokoll, amely megtárgyalja az egyes útválasztók végső redundanciaállapotát azáltal, hogy a két CUBE között (a vezérlőfelületen keresztül) keepalive és hello üzeneteket cserél (a vezérlőfelületen keresztül) —GigabiteThernet3 a fenti ábrán.
-
Transzportmechanizmus a jelátviteli és a médiaállapot ellenőrzésére az aktív és a készenléti útválasztó közötti minden hívás esetében (az adatfelületen keresztül) —GigabiteThernet3 a fenti ábrán.
-
A virtuális IP (VIP) interfész konfigurálása és kezelése a forgalmi interfészekhez (több forgalmi interfész konfigurálható ugyanazon RG-csoport használatával) — GigabiteEthernet 1 és 2 forgalmi interfésznek minősül.
Ezt az RG komponenst kifejezetten úgy kell konfigurálni, hogy támogassa a B2B HA hangját.
Virtuális IP (VIP) címkezelés mind a jelzéshez, mind a médiához
A B2B HA a VIP-re támaszkodik a redundancia elérése érdekében. A CUBE HA pár mindkét CUBE VIP-jének és a kapcsolódó fizikai interfészeknek ugyanazon a LAN alhálózaton kell elhelyezkedniük. A VIP konfigurálása és a VIP interfész egy adott hangalkalmazáshoz (SIP) való kötése kötelező a hangalapú B2B HA támogatás esetén. Az olyan külső eszközökUnified CM, mint például az SBC-hez, a szolgáltató Webex Calling hoz vagy a proxyhoz, VIP-t használnak célként a CUBE HA routereken áthaladó hívásokhoz. Ezért nézőpont Webex Calling ból a CUBE HA párok egyetlen helyi átjáróként működnek.
A létrehozott hívások hívásjelzési és RTP munkamenetinformációit az aktív útválasztóról a készenléti útválasztóra irányítják. Amikor az Active router leáll, a készenléti útválasztó átveszi az irányítást, és folytatja az első router által korábban irányított RTP-adatfolyam továbbítását.
A feladatátvétel idején átmeneti állapotban lévő hívások átállást követően nem maradnak fenn. Például olyan hívások, amelyek még nincsenek teljesen létrehozva, vagy amelyek módosítása folyamatban van egy átviteli vagy megtartás funkcióval. A létrehozott hívások átkapcsolás után leválaszthatók.
A következő követelmények vonatkoznak a CUBE HA helyi átjáróként történő alkalmazásához a hívások állapotú feladatátviteléhez:
-
A CUBE HA nem rendelkezik TDM vagy analóg interfészekkel együtt
-
A Gig1-et és a Gig2-t forgalmi (SIP/RTP) interfészeknek nevezzük, a Gig3 pedig a Redundancia Group (RG) vezérlő/adatinterfésznek
-
Legfeljebb 2 CUBE HA pár helyezhető el ugyanabban a 2. réteg tartományban, az egyik 1. csoportazonosítóval, a másik a 2. csoportazonosítóval. Ha 2 HA-párt konfigurál ugyanazzal a csoportazonosítóval, az RG Control/Data interfészeknek különböző rétegű tartományokhoz kell tartozniuk (vlan, külön kapcsoló)
-
A portcsatorna támogatott mind az RG vezérlés/adat-, mind a forgalmi interfészek számára
-
Minden jelzés/adathordozó a virtuális IP-címről származik
-
Bármikor, amikor egy platform újratöltődik egy CUBE-HA kapcsolatban, mindig készenléti állapotban indul
-
Az összes interfész (Gig1, Gig2, Gig3) alacsonyabb címének ugyanazon a platformon kell lennie
-
Redundancia-interfész azonosítója, a rii-nek egyedülállónak kell lennie egy pár/interfész kombinációra ugyanazon a 2. rétegen
-
Mindkét CUBE konfigurációjának azonosnak kell lennie, beleértve a fizikai konfigurációt is, és azonos típusú platformon és az IOS-XE verzión kell futnia
-
A visszacsatoló interfészek nem használhatók kötőként, mivel mindig fel vannak kapcsolva
-
Több forgalmi (SIP/RTP) interfészek (Gig1, Gig2) konfigurálásához interfészkövetés szükséges
-
A CUBE-HA nem támogatott az RG-vezérlés/adatkapcsolat (Gig3) kereszteződési kábelcsatlakozáson keresztül
-
Mindkét platformnak azonos nak kell lennie, és fizikai kapcsol ón keresztül kell csatlakoztatni az összes hasonló interfészen a CUBE HA működéséhez, azaz A CUBE-1 és a CUBE-2 GE0/0/0-jának ugyanazon a kapcsolón kell véget érnie és így tovább.
-
Nem lehet a WAN lezárni közvetlenül a CUbe-on vagy a Data HA-n mindkét oldalon
-
Mindkét aktív/készenléti állapotban kell lennie ugyanabban az adatközpontban
-
A redundanciához külön L3 interfész használata kötelező (RG Control/Data, Gig3). azaz a forgalomhoz használt interfész nem használható HA keepalive-okhoz és ellenőrzőpontokhoz
-
Feladatátvétel esetén a korábban aktív CUBE tervezés szerint újratöltésen megy keresztül, megőrizve a jelátvitelt és a médiát
Konfigurálja a redundanciát mindkét CUbe-on
A virtuális IP-címek megjelenítéséhez be kell állítania a 2. réteg box-to-box redundanciáját mindkét CUbe-on, amelyet HA párban használni kívánnak.
| 1 |
Konfigurálja az interfész követését globális szinten az interfész állapotának nyomon követéséhez.
A Track CLI-t az RG-ben a hangforgalom interfész állapotának nyomon követésére használják, így az aktív útvonal eléggé aktív szerepe lesz a forgalmi felület leállása után. | ||
| 2 |
Konfiguráljon egy RG-t a VoIP HA-val való használatra az alkalmazás redundancia-almódban.
Íme a konfigurációban használt mezők magyarázata:
| ||
| 3 |
Engedélyezze a box-to-box redundanciát a CUBE alkalmazásban. Konfigurálja az RG-t az előző lépésből.
redundancy-group 1 — A parancs hozzáadásához és eltávolításához újratöltés 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 interfészeket a megfelelő virtuális IP-címekkel az alábbiak szerint, és alkalmazza a redundancia-interfész azonosítóját (rii)
Íme 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ó újratöltési platform mindig a készenléti állapot.
Miután a VCUBE-1 teljesen elindult, mentse el a VCU BE-2 konfigurációját, és töltse be újra.
| ||
| 6 |
Ellenőrizze, hogy a box-to-box konfiguráció a várt módon működik-e. A releváns kimenet félkövér betűvel van kiemel ve. A VCUBE-2-et utoljára töltöttük újra, és a tervezési szempontok szerint; az utolsó újratölthető platform mindig készenléti állapotban lesz.
Ezután folytassa a helyi átjáró konfigurációjával (regisztrációs vagy tanúsítványalapú) mindkét HA CUbe-on. Lásd : Helyi átjáró konfigurálása Cisco IOS az XE rendszeren Webex Calling. |