Ebben a cikkben
Alapvető
Konfigurálja a redundanciát mindkét CUbe-on
A CUBE magas rendelkezésre állásának megvalósítása helyi átjáróként
list-menuEbben a cikkben
list-menuVisszajelzés?

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:

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:

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.

Local Gateway premises-based PSTN deployment

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.

Webex Calling deployment without IP PBX

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.

A typical CUBE HA setup as Local Gateway for a Cisco Webex Calling trunk deployment

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.

A typical CUBE HA setup as Local Gateway for a Cisco Webex Calling trunk deployment

1

Konfigurálja az interfész követését globális szinten az interfész állapotának nyomon követéséhez.

conf t
 track 1 interface GigabitEthernet1 line-protocol
 track 2 interface GigabitEthernet2 line-protocol
 exit

VCUBE-1#conf t
VCUBE-1(config)#track 1 interface GigabitEthernet1 line-protocol
VCUBE-1(config-track)#track 2 interface GigabitEthernet2 line-protocol
VCUBE-1(config-track)#exit
VCUBE-2#conf t
VCUBE-2(config)#track 1 interface GigabitEthernet1 line-protocol
VCUBE-2(config-track)#track 2 interface GigabitEthernet2 line-protocol
VCUBE-2(config-track)#exit

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.

redundancy
  application redundancy
   group 1
    name LocalGateway-HA
    priority 100 failover threshold 75
    control GigabitEthernet3 protocol 1
    data GigabitEthernet3
    timers delay 30 reload 60
    track 1 shutdown
    track 2 shutdown
    exit
   protocol 1
    timers hellotime 3 holdtime 10
   exit
  exit
 exit


VCUBE-1(config)#redundancy
VCUBE-1(config-red)#application redundancy
VCUBE-1(config-red-app)#group 1
VCUBE-1(config-red-app-grp)#name LocalGateway-HA
VCUBE-1(config-red-app-grp)#priority 100 failover threshold 75
VCUBE-1(config-red-app-grp)#control GigabitEthernet3 protocol 1
VCUBE-1(config-red-app-grp)#data GigabitEthernet3
VCUBE-1(config-red-app-grp)#timers delay 30 reload 60
VCUBE-1(config-red-app-grp)#track 1 shutdown
VCUBE-1(config-red-app-grp)#track 2 shutdown
VCUBE-1(config-red-app-grp)#exit
VCUBE-1(config-red-app)#protocol 1
VCUBE-1(config-red-app-prtcl)#timers hellotime 3 holdtime 10
VCUBE-1(config-red-app-prtcl)#exit
VCUBE-1(config-red-app)#exit
VCUBE-1(config-red)#exit
VCUBE-1(config)#

VCUBE-2(config)#redundancy
VCUBE-2(config-red)#application redundancy
VCUBE-2(config-red-app)#group 1
VCUBE-2(config-red-app-grp)#name LocalGateway-HA
VCUBE-2(config-red-app-grp)#priority 100 failover threshold 75
VCUBE-2(config-red-app-grp)#control GigabitEthernet3 protocol 1
VCUBE-1(config-red-app-grp)#data GigabitEthernet3
VCUBE-2(config-red-app-grp)#timers delay 30 reload 60
VCUBE-2(config-red-app-grp)#track 1 shutdown
VCUBE-2(config-red-app-grp)#track 2 shutdown
VCUBE-2(config-red-app-grp)#exit
VCUBE-2(config-red-app)#protocol 1
VCUBE-2(config-red-app-prtcl)#timers hellotime 3 holdtime 10
VCUBE-2(config-red-app-prtcl)#exit
VCUBE-2(config-red-app)#exit
VCUBE-2(config-red)#exit
VCUBE-2(config)#

Íme a konfigurációban használt mezők magyarázata:

  • redundancia — Redundancia módba lép

  • alkalmazásredundancia — Belép az alkalmazás redund ancia-konfigurációs módjába

  • csoport — Redundancia alkalmazáscsoport konfigurációs módjába lép

  • név LocalGateway-HA —Meghatározza az RG-csoport nevét

  • prioritás 100 feladatátvételi küszöb 75 — Megh atározza az RG kezdeti prioritási és feladatátvételi küszöbértékeit

  • időzítők késleltetik 30 újratöltést 60 — Konfigurálja a késleltetés és az újratöltés két alkalmát

    • Késleltetési időzítő, amely az RG csoport inicializálásának és szerepkörök tárgyalásának késleltetéséhez szükséges idő az interfész megjelenése után - Alapértelmezett 30 másodperc. A tartomány 0-10000 másodperc

    • Újratöltés — Ez az idő, amely az RG csoport inicializálásának és szerepkörök megbeszélésének késleltetésére egy újratöltés után — Alapértelmezett 60 másodperc. A tartomány 0-10000 másodperc

    • Alapértelmezett időzítők ajánlottak, bár ezek az időzítők úgy állíthatók be, hogy megfeleljenek a routerek indítása/újratöltése során esetlegesen előforduló további hálózati konvergencia-késleltetésre, annak biztosítása érdekében, hogy az RG protokoll tárgyalása a hálózaton belüli útválasztás stabil pontra konvergenciája után zajlik. Ha például a feladatátvétel után látszik, hogy az új STANDBY legfeljebb 20 másodpercet vesz igénybe az új ACTIVE első RG HELLO csomag megtekintéséhez, akkor az időzítőket a késleltetés figyelembevétele érdekében az időzítők „timers delay 60 reload 120" értékre kell beállítani.

  • GigabiteThernet3 protokoll vezérlése 1 — Konfigurálja a két CUBE közötti keepalive és hello üzenetek cseréjére használt felületet, és megadja a vezérlőfelülethez csatolt protokoll példányt, és belép a redundanciás alkalmazásprotokoll konfigurációs módjába

  • data GigabiteThernet3 — Az adatforgal om ellenőrzéséhez használt interfész konfigurálása

  • nyom@@ on követés —RG csoportos interfészek nyomon követése

  • 1. protokoll — Me ghatározza azt a protokoll példányát, amelyet egy vezérlőfelülethez csatolnak, és belép a redundancia-alkalmazásprotokoll konfigurációs módjába

  • időzítők hellotime 3 holdtime 10 — Konfigurálja a hellotime és a hold time két időzítőjét:

    • Hellotime— Az egymást követő üdvözlőüzenetek közötti intervallum - Alapértelmezett 3 másodperc. A tartomány 250 millimásodperc-254 másodperc

    • Tartási idő — A Hello üzenet kézhezvétele és a küldő útválasztó meghibásodásának feltételezése közötti időtartam. Ennek az időtartamnak nagyobbnak kell lennie, mint a hello-time - Alapértelmezett 10 másodperc. A tartomány 750 millimásodperc-255 másodperc

      Javasoljuk, hogy az eltartási időzítőt úgy állítsa be, hogy legalább háromszorosa legyen a hellotime időzítő értékének.

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. voice service voip Ez lehetővé teszi a CUBE alkalmazás számára a redundanciafolyamat vezérlését.

voice service voip
   redundancy-group 1
   exit

VCUBE-1(config)#voice service voip
VCUBE-1(config-voi-serv)#redundancy-group 1
% Created RG 1 association with Voice B2B HA; reload the router for the new configuration to take effect
VCUBE-1(config-voi-serv)# exit
VCUBE-2(config)#voice service voip
VCUBE-2(config-voi-serv)#redundancy-group 1
% Created RG 1 association with Voice B2B HA; reload the router for the new configuration to take effect
VCUBE-2(config-voi-serv)# exit

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)

VCUBE-1(config)#interface GigabitEthernet1
VCUBE-1(config-if)# redundancy rii 1
VCUBE-1(config-if)# redundancy group 1 ip 198.18.1.228 exclusive
VCUBE-1(config-if)# exit
VCUBE-1(config)#
VCUBE-1(config)#interface GigabitEthernet2
VCUBE-1(config-if)# redundancy rii 2
VCUBE-1(config-if)# redundancy group 1 ip 198.18.133.228 exclusive
VCUBE-1(config-if)# exit
VCUBE-2(config)#interface GigabitEthernet1
VCUBE-2(config-if)# redundancy rii 1
VCUBE-2(config-if)# redundancy group 1 ip 198.18.1.228 exclusive
VCUBE-2(config-if)# exit
VCUBE-2(config)#
VCUBE-2(config)#interface GigabitEthernet2
VCUBE-2(config-if)# redundancy rii 2
VCUBE-2(config-if)# redundancy group 1 ip 198.18.133.228 exclusive
VCUBE-v(config-if)# exit

Íme a konfigurációban használt mezők magyarázata:

  • redundancia-rii — Konfigurálja a redundanciacsoport redundancia-interfész azonosítóját. Virtuális MAC (VMAC) cím létrehozásához szükséges. Ugyanazt a rii ID értéket kell használni minden olyan router (ACTIVE/STANDBY) felületén, amely azonos VIP-vel rendelkezik.

    Ha egynél több B2B pár van ugyanazon a LAN hálózaton, minden párnak egyedi rii-azonosítókkal KELL rendelkeznie a megfelelő interfészükön (az ütközés elkerülése érdekében). A redundan cia alkalmazáscsoport all megjelenítése parancs nak meg kell jelölnie a helyes helyi és társ információkat.

  • 1. redundanciacsoport — tár sítja az interfészt a fenti 2. lépésben létrehozott redundanciacsoporthoz. Konfigurálja az RG-csoportot, valamint az ehhez a fizikai felülethez hozzárendelt VIP-t.

    A redundanciához külön interfész használata kötelező, vagyis a hangforgalomhoz használt felület nem használható a fenti 2. lépésben meghatározott vezérlő- és adatfelületként. Ebben a példában a Gigabit interfész 3 használható az RG vezérléséhez/adatokhoz

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.

VCUBE-1#wr
Building configuration...
[OK]
VCUBE-1#reload
Proceed with reload? [confirm]

Miután a VCUBE-1 teljesen elindult, mentse el a VCU BE-2 konfigurációját, és töltse be újra.

VCUBE-2#wr
Building configuration...
[OK]
VCUBE-2#reload
Proceed with reload? [confirm]
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.


VCUBE-1#show redundancy application group all
Faults states Group 1 info:
       Runtime priority: [100]
               RG Faults RG State: Up.
                       Total # of switchovers due to faults:           0
                       Total # of down/up state changes due to faults: 0
Group ID:1
Group Name:LocalGateway-HA
  
Administrative State: No Shutdown
Aggregate operational state: Up
My Role: ACTIVE
Peer Role: STANDBY
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: ACTIVE
         Peer RF state: STANDBY HOT

RG Protocol RG 1
------------------
        Role: Active
        Negotiation: Enabled
        Priority: 100
        Protocol state: Active
        Ctrl Intf(s) state: Up
        Active Peer: Local
        Standby Peer: address 10.1.1.2, priority 100, intf Gi3
        Log counters:
                role change to active: 1
                role change to standby: 1
                disable events: rg down state 0, rg shut 0
                ctrl intf events: up 1, down 0, admin_down 0
                reload events: local request 0, peer request 0

RG Media Context for RG 1
--------------------------
        Ctx State: Active
        Protocol ID: 1
        Media type: Default
        Control Interface: GigabitEthernet3
        Current Hello timer: 3000
        Configured Hello timer: 3000, Hold timer: 10000
        Peer Hello timer: 3000, Peer Hold timer: 10000
        Stats:
            Pkts 1509, Bytes 93558, HA Seq 0, Seq Number 1509, Pkt Loss 0
            Authentication not configured
            Authentication Failure: 0
            Reload Peer: TX 0, RX 0
            Resign: TX 0, RX 0
    Standy Peer: Present. Hold Timer: 10000
            Pkts 61, Bytes 2074, HA Seq 0, Seq Number 69, Pkt Loss 0

VCUBE-1#

VCUBE-2#show redundancy application group all
Faults states Group 1 info:
       Runtime priority: [100]
               RG Faults RG State: Up.
                       Total # of switchovers due to faults:           0
                       Total # of down/up state changes due to faults: 0
Group ID:1
Group Name:LocalGateway-HA
  
Administrative State: No Shutdown
Aggregate operational state: Up
My Role: STANDBY
Peer Role: ACTIVE
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: ACTIVE
         Peer RF state: STANDBY HOT

RG Protocol RG 1
------------------
        Role: Active
        Negotiation: Enabled
        Priority: 100
        Protocol state: Active
        Ctrl Intf(s) state: Up
        Active Peer: address 10.1.1.2, priority 100, intf Gi3
        Standby Peer: Local
        Log counters:
                role change to active: 1
                role change to standby: 1
                disable events: rg down state 0, rg shut 0
                ctrl intf events: up 1, down 0, admin_down 0
                reload events: local request 0, peer request 0

RG Media Context for RG 1
--------------------------
        Ctx State: Active
        Protocol ID: 1
        Media type: Default
        Control Interface: GigabitEthernet3
        Current Hello timer: 3000
        Configured Hello timer: 3000, Hold timer: 10000
        Peer Hello timer: 3000, Peer Hold timer: 10000
        Stats:
            Pkts 1509, Bytes 93558, HA Seq 0, Seq Number 1509, Pkt Loss 0
            Authentication not configured
            Authentication Failure: 0
            Reload Peer: TX 0, RX 0
            Resign: TX 0, RX 0
    Standy Peer: Present. Hold Timer: 10000
            Pkts 61, Bytes 2074, HA Seq 0, Seq Number 69, Pkt Loss 0

VCUBE-2#

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.

Hasznos volt ez a cikk?
Hasznos volt ez a cikk?