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:

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:

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.

Helyi átjáró telephelyalapú PSTN-telepítése

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.

Webex Calling telepítése IP PBX nélkül

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.

Tipikus CUBE HA-beállítás 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.

Tipikus CUBE HA-beállítás helyi átjáróként a Cisco Webex Calling trönk telepítéséhez

1

Konfigurálja az interfész nyomon 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 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.

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)#

Az ebben a konfigurációban használt mezők magyarázata:

  • redundancia—A redundancia módba lép

  • alkalmazás redundancia – Az alkalmazás redundancia konfigurációs módjának megnyitása

  • csoport – a redundancia alkalmazáscsoport konfigurációs módjának megadása

  • LocalGateway-HA név – az RG-csoport nevét határozza meg

  • 100. prioritás feladatátvétel küszöbértéke 75 – Az RG kezdeti prioritását és feladatátvétel küszöbértékeit adja meg

  • időzítő késleltetés 30 újratöltés 60 – kétszer konfigurálja a késleltetést és az újratöltést

    • Késleltetési időzítő, amely az RG-csoport inicializálásának és szerepegyeztetésének késleltetéséhez szükséges idő a felület megjelenése után – Alapértelmezett 30 másodperc. Az időtartomány 0–10000 másodperc

    • Újratöltés—Ez az az időtartam, amely az RG-csoport inicializálásának és szerepkör-egyeztetésnek az újratöltés után történő késleltetéséhez szükséges – Alapértelmezett 60 másodperc. Az időtartomány 0–10000 másodperc

    • Az alapértelmezett időzítők ajánlottak, bár ezek az időzítők módosíthatók az útválasztók indítás/újratöltése során esetlegesen fellépő további hálózati konvergencia-késleltetés figyelembevétele érdekében, annak biztosítása érdekében, hogy az RG protokoll egyeztetése a hálózaton belüli útválasztás után történjen meg egy stabil ponthoz való közeledést követően. Például, ha a feladatátvétel után látható, hogy az új KÉSZENLÉT legfeljebb 20 másodpercig tart, amíg az új ACTIVE első RG HELLO csomag megjelenik, akkor az időzítőket úgy kell beállítani, hogy az „időzítők késleltetése 60 újratöltés 120”, hogy a késleltetés tényezője legyen.

  • GigabitEthernet3 1-es protokoll vezérlése – Konfigurálja a két CUBE között az életképes és üdvözlő üzenetek cseréjére használt felületet, és megadja azt a protokollpéldányt, amelyet egy vezérlőfelülethez csatolnak, és megadja a redundancia alkalmazás protokoll konfigurációs módját

  • data GigabitEthernet3 – Az adatforgalom ellenőrzőmutatására használt felületet konfigurálja

  • nyomon követés – Interfészek RG csoport követése

  • 1. protokoll – Megadja azt a protokollpéldányt, amelyet a vezérlőinterfészhez csatolnak, és megadja a redundancia alkalmazás protokoll konfigurációs módját

  • Időzítők hellotime 3 tarttime 10 – A hellotime és a tarttime két időzítőt konfigurálja:

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

    • Tartási idő – Az üdvözlő üzenet fogadása és a küldő útválasztó sikertelenségének vélelme közötti intervallum. Ennek az időtartamnak nagyobbnak kell lennie, mint a üdvözlőidő – Alapértelmezett 10 másodperc. A tartomány 750 ezredmásodperc és 255 másodperc között van

      Javasoljuk, hogy a tarttime időzítőt úgy állítsa be, hogy a hellotime időzítő értékének legalább 3-szorosa legyen.

3

Engedélyezze a dobozok közötti redundanciát a CUBE alkalmazáshoz. Konfigurálja az RG-t a(z) voice service voip alatti előző lépésből. Ez lehetővé teszi a CUBE alkalmazás számára a redundancia folyamat 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

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)

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

Az ebben a konfigurációban használt mezők magyarázata:

  • redundancia rii – Konfigurálja a redundancia interfész azonosítót a redundanciacsoporthoz. Virtuális MAC (VMAC) cím generálásához szükséges. Ugyanazt a rii ID értéket kell használni minden olyan router interfészén (AKTÍV/KÉSZENLÉTI), amely ugyanazt a VIP-t tartalmazza.

    Ha egynél több B2B-pár van ugyanazon a LAN-on, mindegyik párnak egyedi RII-azonosítóval KELL rendelkeznie a megfelelő interfészeken (az ütközés megelőzése érdekében). A redundancia alkalmazáscsoport összes parancsának a helyes helyi és peer információkat kell jeleznie.

  • 1. redundanciacsoport – Összekapcsolja a felületet a fenti 2. lépésben létrehozott redundanciacsoporttal. Konfigurálja az RG-csoportot, valamint a fizikai interfészhez hozzárendelt VIP-t.

    A redundanciához külön interfészt kell használni, azaz a hangforgalomhoz használt interfészt nem lehet a fenti 2. lépésben meghatározott vezérlési és adatinterfészként használni. Ebben a példában a Gigabit felület 3 az RG vezérlésére/adataira szolgál

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.

VCUBE-1#wr


                        Building configuration...
                      


                        [OK]
                      

VCUBE-1#reload


                        Proceed with reload? [confirm]
                      

Miután a VCUBE-1 teljesen elindul, mentse a VCUBE-2 konfigurációját, majd töltse be újra.

VCUBE-2#wr


                        Building configuration...
                      


                        [OK]
                      

VCUBE-2#reload


                        Proceed with reload? [confirm]
                      

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.


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á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.