A Local Gateway (LGW) az egyetlen lehetőség a helyszíni PSTN-hozzáférés biztosítására a Cisco Webex Calling ügyfelek számára. Ennek a dokumentumnak az a célja, hogy segítsen a helyi átjáró konfigurációjának kialakításában a CUBE magas rendelkezésre állású, aktív/készenléti CUBE-k használatával az aktív hívások állapot-teljes feladatátvételéhez.
Alapjait
Előfeltételek
Mielőtt a CUBE HA-t a Webex-hívás helyi átjárójaként telepeskedne le, győződjön meg arról, hogy részletesen ismeri a következő fogalmakat:
Layer 2 box-to-box redundancia a CUBE Enterprise-nal az állapot-szerű hívásmegőrzés érdekében
Az ebben a cikkben megadott konfigurációs irányelvek egy dedikált helyi átjáróplatformot feltételeznek, amely nem rendelkezik meglévő hangkonfigurációval. 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, fordítson nagy figyelmet az alkalmazott konfigurációra annak biztosítása érdekében, hogy a meglévő hívásáramlások é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óként IOS-XE 16.12.2-es vagy újabb verziót igényel, valamint egy olyan platformot, amelyen a CUBE HA és az LGW funkciók is támogatottak.
A cikkben szereplő show parancsok és naplók a Cisco IOS-XE 16.12.2 vCUBE (CSR1000v) rendszeren megvalósított minimális szoftverkiadásán 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
Cisco preferált architektúra Cisco Webex Calling -https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Webex hívási megoldás – áttekintés
A Cisco Webex Calling egy együttműködési ajánlat, amely több bérlős felhőalapú alternatívát kínál a helyszíni PBX telefonszolgáltatással szemben, több PSTN-opcióval az ügyfelek számára.
A cikk középpontjában a Helyi átjáró telepítése (az alábbiakban látható) áll. A Webex Calling helyi átjáró (premise-alapú PSTN) törzse lehetővé teszi az ügyfél tulajdonában lévő PSTN-szolgáltatáshoz való csatlakozást. Emellett 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 onnan érkező összes kommunikáció biztonságos a SIP TLS-átvitelével és az SRTP-hez a médiához.
Az alábbi ábra egy meglévő IP PBX nélküli Webex Calling telepítést jelenít meg, és egyetlen vagy többhelyes telepítésre alkalmazható. A cikkben ismertetett konfiguráció ezen a telepítésen alapul.
2. réteg doboztól dobozig redundanciája
CUBE HA layer 2 box-to-box redundancia a Redundancy Group (RG) infrastruktúra protokollt használja aktív/készenléti útválasztópár kialakításához. Ez a pár ugyanazon a virtuális IP-címen (VIP) osztozik a megfelelő interfészeken, és folyamatosan állapotüzeneteket cserél. A CUBE munkamenet-információk az útválasztók között ellenőrzés alatt állnak, lehetővé téve a készenléti útválasztó számára, hogy azonnal átvegye az összes CUBE hívásfeldolgozási felelősséget, ha az aktív útválasztó üzemen kívül megy, ami a jelek és az adathordozók állapottudatos megőrzését eredményezi.
Az ellenőrzőpont a médiacsomagokkal csatlakoztatott hívásokra korlátozódik. A tranzithívások nem ellenőrzik a hegyet (például egy próbálkozó vagy csengő állapot). Ebben a cikkben a CUBE HA a CUBE high availability (HA) Layer 2 Box-to-box (B2B) redundanciára hivatkozik az állapot-tudatos hívásmegőrzés érdekében |
Az IOS-XE 16.12.2-es rendszertől függően a CUBE HA helyi átjáróként telepíthető a Cisco Webex Calling trunk (Premises-based PSTN) telepítések számára, és ebben a cikkben foglalkozunk a tervezési megfontolásokkal és konfigurációkkal. Ez 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éséhez.
Redundanciacsoport Infra komponens
A Redundancy Group (RG) Infra komponens biztosítja a két CUBE közötti dobozról dobozra kommunikációs infrastruktúra-támogatást, és tárgyal a végső stabil redundancia állapotról. Ez az összetevő a következőket is biztosítja:
HSRP-szerű protokoll, amely az egyes útválasztók végső redundanciaállapotát tárgyalja a két CUBE közötti keepalive és hello üzenetek cseréjével (a vezérlőfelületen keresztül) - GigabitEthernet3 a fenti ábrán.
Az aktívtól a készenléti útválasztóig (az adatfelületen keresztül) érkező egyes hívások jel- és médiaállapotának ellenőrzésére szolgáló átviteli mechanizmus – GigabitEthernet3 a fenti ábrán.
A virtuális IP (VIP) interfész konfigurálása és kezelése a közlekedési interfészekhez (több forgalmi interfész konfigurálható ugyanazzal az RG csoporttal) – a GigabitEthernet 1 és 2 forgalmi 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ímkezelés mind a jelzéshez, mind a médiához
A B2B HA a VIP-re támaszkodik a redundancia eléréséhez. A CUBE HA pár mindkét CUBE VIP és kapcsolódó fizikai interfészének ugyanazon a LAN alhálózaton kell lennie. A VIP konfigurációja és a VIP interfész kötődése egy adott hangalkalmazáshoz (SIP) kötelező a hang B2B HA támogatásához. Az olyan külső eszközök, mint a Unified CM, a Webex Calling access SBC, a szolgáltató vagy a proxy, a VIP-t használják cél IP-címként a CUBE HA útválasztókon áthaladó hívásokhoz. Ezért a Webex Calling szempontjából a CUBE HA párok egyetlen helyi átjáróként működnek.
A létrehozott hívások hívásjele és RTP-munkamenet-információi az aktív útválasztótól a készenléti útválasztóig vannak ellenőrizve. Amikor az Aktív útválasztó leáll, a készenléti útválasztó átveszi az irányítást, és folytatja az rtp-adatfolyam továbbítását, amelyet korábban az első útválasztó irányított.
A feladatátvételkor átmeneti állapotban lévő hívások nem maradnak meg az átállás után. Például azok a hívások, amelyek még nincsenek teljesen létrehozva, vagy átmozgatási vagy visszatartási funkcióval módosulnak. A létrehozott hívások az átállás után megszakadhatnak.
A CUBE HA helyi átjáróként való használatára a következő követelmények vonatkoznak a hívások állapot-teljes feladatátvételé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, a Gig3-at pedig redundanciacsoport (RG) vezérlő/adat interfésznek nevezik.
Legfeljebb 2 CUBE HA pár helyezhető el ugyanabban a 2. réteg tartományában, az egyik 1-es csoportazonosítóval, a másik pedig 2-es csoportazonosítóval. Ha 2 HA-pár konfigurálása ugyanazzal a csoportazonosítóval, az RG-vezérlő/adat interfészeknek különböző 2. rétegtartományokhoz kell tartoznia (vlan, külön kapcsoló)
A portcsatorna mind az RG Control/data, mind a traffic interfaces számára támogatott
Minden jelzés/adathordozó a virtuális IP-címről/-forrásból származik
Bármikor, amikor egy platform újra betöltődik egy CUBE-HA kapcsolatban, mindig készenléti állapotban indul el
Az összes interfész (Gig1, Gig2, Gig3) alacsonyabb címének ugyanazon a platformon kell lennie
Redundancia interfész azonosítója, rii kell egyedi egy pár / interfész kombináció ugyanazon a rétegen 2
Mindkét CUBE konfigurációjának azonosnak kell lennie, beleértve a fizikai konfigurációt is, és ugyanazon a platformon és IOS-XE verzión kell futnia
A visszacsatolási illesztők nem használhatók kötésként, mivel mindig fent vannak
A több forgalmi (SIP/RTP) interfész (Gig1, Gig2) használatához interfészkövetésre van szükség
A CUBE-HA nem támogatott crossover kábelkapcsolaton keresztül az RG-control/data linkhez (Gig3)
Mindkét platformnak azonosnak kell lennie , és fizikai kapcsolóval kell kapcsolódniuk a CUBE HA működéséhez, azaz a CUBE-1 és CUBE-2 GE0/0/0-nak ugyanazon a kapcsolón kell végződnie, és így tovább.
A WAN nem szüntethető meg közvetlenül a CUBE-kon vagy a Data HA-n mindkét oldalon
Az aktív/készenléti üzemmódnak ugyanabban az adatközpontban kell lennie
A redundancia esetén kötelező külön L3 interfészt használni (RG Control/data, Gig3). azaz a forgalomhoz használt interfész nem használható HA-keepalives és checkpointing
Feladatátvételkor a korábban aktív CUBE egy tervezéssel történő újratöltésen megy keresztül, megőrizve a jelzéseket és az adathordozót
Redundancia konfigurálása mindkét CUBE-n
A 2. réteg doboz-doboz redundanciát mindkét CUBE-n be kell állítania, amelyet HA-párban kíván használni a virtuális IP-k felmásához.
1 | Konfigurálja a kapcsolatkövetést globális szinten a kapcsolat állapotának nyomon követéséhez.
A CLI sávot az RG-ben használják a hangforgalmi felület állapotának nyomon követésére, így az aktív útvonal a forgalmi felület leállása után meglehetősen aktív szerepet tölt be. |
||||||
2 | Konfiguráljon egy hálózati RG-t a VoIP HA alkalmazásredundancia almódban való használatra.
Az alábbiakban ismerteted az ebben a konfigurációban használt mezőket:
|
||||||
3 | Box-to-box redundancia engedélyezése a CUBE alkalmazáshoz. Konfigurálja az RG-t az előző lépésből
redundanciacsoport 1– A parancs hozzáadásához és eltávolításához újra be kell tölteni a frissített konfigurációt. A teljes konfiguráció alkalmazása után újratöltjük a platformokat. |
||||||
4 | Konfigurálja a Gig1 és Gig2 interfészeket a megfelelő virtuális EM-kkel az alábbiak szerint, és alkalmazza a redundanciafelület azonosítóját (rii)
Az alábbiakban ismerteted az ebben a konfigurációban használt mezőket:
|
||||||
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.
Miután a VCUBE-1 teljesen elindul, mentse el a VCUBE-2 konfigurációját , és töltse be újra.
|
||||||
6 | Ellenőrizze, hogy a doboztól a dobozig konfiguráció a várt módon működik-e. A releváns kimenet félkövérrel van kiemelve. A VCUBE-2-t utoljára és a tervezési szempontok szerint újratöltöttük ; az utolsó újratöltési platform mindig készenlétilesz .
|
Helyi átjáró konfigurálása mindkét CUBE-n
Példakonfigurációnkban a Control Hub következő törzsadatait használjuk a Helyi átjáró konfigurációjának létrehozásához mindkét platformon, a VCUBE-1-en és a VCUBE-2-n. A beállítás felhasználóneve és jelszava a következő:
Felhasználónév: Hussain1076LGU_
Jelszó: lOV12MEaZx
1 | Győződjön meg arról, hogy a jelszóhoz konfigurációs kulcs van létrehozva az alábbi parancsokkal, mielőtt az a hitelesítő adatokban vagy a megosztott titkos kulcsokban használható lenne. A 6. típusú jelszavak titkosítva vannak az AES titkosítással és ezzel a felhasználó által definiált konfigurációs kulccsal.
Itt található a Helyi átjáró konfigurációja, amely mindkét platformra vonatkozik a fent megjelenített Control Hub paraméterek alapján, mentse és töltse be újra. A Control Hub SIP Kivonat hitelesítő adatai félkövérrel vannak kiemelve.
A show parancs kimenetének megjelenítéséhez újratöltöttük a VCUBE-2-t, majd a VCUBE-1-et, így a VCUBE-1 készenléti KOCKA és a VCUBE-2 az aktív CUBE |
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éssel rendelkező SBC-vel. Tekintse meg a következő megjelenítési parancsok kimenetét. redundanciaalkalmazási csoport megjelenítése 1 sip-ua-regiszter állapotának megjelenítése
A fenti kimenetből láthatja, hogy a VCUBE-2 az aktív LGW, amely fenntartja a regisztrációt a Webex Calling access SBC-vel, míg a "show sip-ua regiszter állapota" kimenete üres a VCUBE-1-ben |
3 | Most engedélyezze a következő hibakereséseket a VCUBE-1-en
|
4 | Szimulálja a feladatátvételt a következő parancs kiadásával az aktív LGW-n, ebben az esetben a VCUBE-2.
Az ACTIVE-ról a KÉSZENLÉTI LGW-re való áttérés a következő forgatókönyvben történik a fent felsorolt CLI mellett
|
5 | Ellenőrizze, hogy a VCUBE-1 regisztrált-e a Webex Calling access SBC-n. A VCUBE-2 már újratöltötte volna.
A VCUBE-1 az aktív LGW. |
6 | Nézze meg a megfelelő hibakeresési naplót a VCUBE-1-en, amely SIP REGISTER-et küld a Webex Calling-nak a virtuális IP-n keresztül, és 200 OK-t kap.
|