Grunnleggende

Forutsetninger

Før du distribuerer Cisco Unified Border Element (CUBE) High Availability (HA) som en lokal gateway for Webex Calling, må du sørge for at du har en grundig forståelse av følgende konsepter:

Konfigurasjonsretningslinjene i denne artikkelen forutsetter en dedikert lokal gateway-plattform uten eksisterende talekonfigurasjon. Hvis en eksisterende CUBE-bedriftsdistribusjon endres for også å bruke den lokale gateway-funksjonen for Cisco Webex Calling, må du være nøye med konfigurasjonen som brukes for å sikre at eksisterende anropsflyter og -funksjoner ikke blir avbrutt, og sørg for at du overholder CUBE HA-designkravene.

Maskinvare- og programvarekomponenter

CUBE HA som lokal gateway krever IOS-XE versjon 17.9.1 eller nyere og en plattform som støtter både CUBE HA- og LGW-funksjoner.

Kommandoene og loggene i denne artikkelen er basert på minimum programvareutgivelse av Cisco IOS-XE 17.9.1 implementert på en vCUBE (CSR 8000v).

Referansemateriale

Her er noen detaljerte CUBE HA konfigurasjonsveiledninger for ulike plattformer:

Oversikt over Webex Calling-løsning

Cisco Webex Calling er et samarbeidstilbud som tilbyr et skybasert alternativ for flere leietakere til lokal PBX-telefontjeneste med flere PSTN-alternativer for kunder.

Distribusjonen av den lokale gatewayen (representert nedenfor) er fokuset i denne artikkelen. Lokal gateway (lokalbasert PSTN)-trunk i Webex Calling tillater tilkobling til en kundeeid PSTN-tjeneste. Den gir også tilkobling til en lokal IP PBX-distribusjon, for eksempel Cisco Unified CM. All kommunikasjon til og fra skyen er sikret ved hjelp av TLS-transport for SIP og SRTP for medier.

Lokal gateway-basert PSTN-distribusjon

Figuren nedenfor viser en Webex Calling-distribusjon uten eksisterende IP PBX og gjelder for en enkelt distribusjon eller en distribusjon på flere steder. Konfigurasjonen beskrevet i denne artikkelen er basert på denne distribusjonen.

Webex Calling-distribusjon uten IP PBX

Lag 2 boks-til-boks-redundans

CUBE HA lag 2 boks-til-boks-redundans bruker infrastrukturprotokollen Redundancy Group (RG) til å danne et aktivt/ventebypar av rutere. Dette paret deler den samme virtuelle IP-adressen (VIP) på tvers av sine respektive grensesnitt og utveksler statusmeldinger kontinuerlig. CUBE-øktinformasjon er sjekket på tvers av ruterparet, slik at standbyruteren kan ta over alle CUBE-samtalebehandlingsansvar umiddelbart hvis den aktive ruteren går ut av drift, noe som resulterer i stateful bevaring av signalisering og media.

Kontroll av peking er begrenset til tilkoblede samtaler med mediapakker. Anrop som er i transit, blir ikke sjekket (for eksempel en forsøks- eller ringestatus).

I denne artikkelen vil CUBE HA referere til CUBE High Availability (HA) Layer 2 Box-to-Box (B2B) redundans for stateful samtalebevaring.

Fra og med IOS-XE 17.9.1 KAN CUBE HA distribueres som lokal gateway for Cisco Webex Calling-trunkdistribusjoner (lokalt basert PSTN). Denne artikkelen vil diskutere designhensyn og konfigurasjoner. Figuren viser et typisk CUBE HA-oppsett som lokal gateway for en Cisco Webex Calling-trunkdistribusjon.

Et typisk CUBE HA-oppsett som lokal gateway for en Cisco Webex Calling-trunkdistribusjon

Redundancy-gruppe infra-komponent

Redundancy Group (RG) Infra-komponenten gir støtte for kommunikasjonsinfrastruktur mellom de to CUBE-ene og forhandler den endelige stabile redundanstilstanden. Denne komponenten gir også:

  • En HSRP-lignende protokoll som forhandler den endelige overflødighetstilstanden for hver ruter ved å utveksle opprettholder og hei-meldinger mellom de to CUBE-ene (via kontrollgrensesnittet) – GigabitEthernet3 i figuren ovenfor.

  • En transportmekanisme for å kontrollere signal- og medietilstanden for hver samtale fra den aktive til standbyruteren (via datagrensesnittet) – GigabitEthernet3 i figuren ovenfor.

  • Konfigurasjon og administrasjon av det virtuelle IP (VIP)-grensesnittet for trafikkgrensesnittet (flere trafikkgrensesnitt kan konfigureres ved hjelp av samme RG-gruppe) – GigabitEthernet 1 og 2 regnes som trafikkgrensesnitt.

Denne RG-komponenten må konfigureres spesielt for å støtte tale B2B HA.

Administrasjon av virtuell IP (VIP)-adresse for både signalisering og medier

B2B HA er avhengig av VIP for å oppnå redundans. VIP og tilhørende fysiske grensesnitt på begge CUBE-ene i CUBE HA-paret må ligge på samme LAN-subnett. Konfigurasjon av VIP og binding av VIP-grensesnittet til et bestemt taleprogram (SIP) er obligatorisk for støtte for tale B2B HA. Eksterne enheter som Unified CM, Webex Calling-tilgang SBC, tjenesteleverandør eller proxy, bruker VIP som mål-IP-adresse for samtaler som går gjennom CUBE HA-ruterne. Fra et Webex Calling-synspunkt fungerer CUBE HA-paret derfor som én enkelt lokal gateway.

Anropssignalering og RTP-øktinformasjon for etablerte samtaler sjekkes fra den aktive ruteren til standbyruteren. Når den aktive ruteren går ned, tar standbyruteren over og fortsetter å viderekoble RTP-strømmen som tidligere ble rutet av den første ruteren.

Samtaler i midlertidig tilstand ved failover vil ikke bli bevart etter overgang. For eksempel anrop som ikke er fullstendig etablert ennå, eller som er i ferd med å bli endret med en overførings- eller ventefunksjon. Etablerte samtaler kan kobles fra etter bytte.

Følgende krav er gjeldende for bruk av CUBE HA som lokal gateway for stateful failover av samtaler:

  • CUBE HA kan ikke ha samtidig plassert TDM eller analoge grensesnitt

  • Gig1 og Gig2 kalles trafikkgrensesnitt (SIP/RTP), og Gig3 er Redundancy Group (RG) Control/Data-grensesnitt

  • Maksimalt 2 CUBE HA-par kan plasseres i samme lag 2 domene, ett med gruppe-ID 1 og den andre med gruppe-id 2. Hvis du konfigurerer 2 HA-par med samme gruppe-ID, må RG Control/Data-grensesnitt tilhøre forskjellige lag 2 domener (vlan, separat svitsj)

  • Portkanal støttes for både RG Control/data og trafikkgrensesnitt

  • All signalisering/media kommer fra/til den virtuelle IP-adressen

  • Når en plattform lastes på nytt i et CUBE-HA-forhold, starter den alltid opp som Standby

  • Lavere adresse for alle grensesnitt (Gig1, Gig2, Gig3) skal være på samme plattform

  • Redundancy Interface Identifier, rii skal være unik for en par/grensesnittkombinasjon på samme lag 2

  • Konfigurasjonen på begge CUBE-ene må være identisk, inkludert fysisk konfigurasjon, og må kjøre på samme type plattform og IOS-XE-versjon

  • Loopback-grensesnitt kan ikke brukes så bind som de alltid er opp

  • Grensesnitt for flere trafikk (SIP/RTP) (Gig1, Gig2) krever at grensesnittsporing konfigureres

  • CUBE-HA støttes ikke over en krysskabel-tilkobling for RG-kontroll/datatilkobling (Gig3)

  • Begge plattformene må være identiske og være tilkoblet via en fysisk bryter på tvers av alle likelige grensesnitt for at CUBE HA skal fungere, dvs. GE0/0/0 av CUBE-1 og CUBE-2 må avsluttes på samme bryter og så videre.

  • Kan ikke ha WAN avsluttet på CUBE-er direkte eller Data HA på begge sider

  • Begge aktive/standbyene må være i samme datasenter

  • Det er obligatorisk å bruke et eget L3-grensesnitt for redundans (RG Control/Data, Gig3). dvs. grensesnitt som brukes for trafikk, kan ikke brukes for HA-oppbevaringssystemer og kontrollpeking

  • Ved failover gjennomgår den tidligere aktive CUBE en reload ved design, og bevarer signalering og media

Konfigurer redundans på begge CUBE-ene

Du må konfigurere boks-til-boks-redundans for lag 2 på begge CUBE-ene som skal brukes i et HA-par for å hente opp virtuelle IP-er.

Et typisk CUBE HA-oppsett som lokal gateway for en Cisco Webex Calling-trunkdistribusjon

1

Konfigurer grensesnittsporing på globalt nivå for å spore statusen til grensesnittet.

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

Track CLI brukes i RG til å spore taletrafikkgrensesnittet slik at den aktive ruten vil fjerne sin aktive rolle etter at trafikkgrensesnittet er nede.

2

Konfigurer en RG for bruk med VoIP HA i undermodusen for programredundans.

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

Her er en forklaring på feltene som brukes i denne konfigurasjonen:

  • redundans– går inn i redundans-modus

  • Applikasjonsredundans– Går inn i konfigurasjonsmodus for applikasjonsredundans

  • gruppe – går inn i konfigurasjonsmodus for redundans-programgruppe

  • navn LocalGateway-HA– Definerer navnet på RG-gruppen

  • prioritet 100 failover-terskel 75 – Angir første prioritet og failover-terskel for en RG

  • Timers forsinkelse 30 omlasting 60 – Konfigurerer to ganger for forsinkelse og omlasting

    • Forsinkelsestidtaker som er hvor lang tid det tar å forsinke RG-gruppens initialisering og rolleforhandling etter at grensesnittet kommer opp – Standard 30 sekunder. Området er 0-10000 sekunder

    • Reload – Dette er tiden det tar å forsinke initialisering av RG-gruppe og rolleforhandling etter en reload – standard 60 sekunder. Området er 0-10000 sekunder

    • Standardtidtakere anbefales, selv om disse tidtakerne kan justeres for å imøtekomme eventuelle ekstra forsinkelser i nettverkskonvergensen som kan oppstå under oppstart/omlasting av rutere, for å garantere at RG-protokollforhandlingen finner sted etter at ruting i nettverket har konvertert til et stabilt punkt. Hvis det for eksempel vises etter failover at det tar opptil 20 sekunder før den nye STANDBY ser den første RG HELLO-pakken fra den nye ACTIVE, bør tidtakeren justeres til «tidtakerforsinkelse 60 reload 120» for å faktorere denne forsinkelsen.

  • Control GigabitEthernet3-protokoll 1 – Konfigurerer grensesnittet som brukes til å utveksle opprettholder live- og hei-meldinger mellom de to CUBE-ene, og angir protokollforekomsten som vil bli knyttet til et kontrollgrensesnitt og går inn i konfigurasjonsmodus for redundancy-program-protokoll

  • GigabitEthernet3-data – Konfigurerer grensesnittet som brukes til å kontrollere datatrafikk

  • sporing– RG-gruppesporing av grensesnitt

  • protokoll 1 – angir protokollforekomsten som vil bli knyttet til et kontrollgrensesnitt og går inn i konfigurasjonsmodus for redundant program-protokoll

  • Timers hellotid 3 holdtid 10– Konfigurerer de to tidtakerne for hellotid og holdtid:

    • Hellotime – Intervall mellom påfølgende hei-meldinger – Standard 3 sekunder. Området er 250 millisekunder - 254 sekunder

    • Ventetid – Intervallet mellom mottak av en Hei-melding og antagelsen om at senderruteren mislyktes. Denne varigheten må være lengre enn hei-tiden – Standard 10 sekunder. Området er 750 millisekunder-255 sekunder

      Vi anbefaler at du konfigurerer holdtidtakeren til å være minst 3 ganger verdien av hellotime-tidtakeren.

3

Aktiver boks-til-boks-redundans for CUBE-programmet. Konfigurer RG fra forrige trinn under voice service voip. Dette gjør det mulig for CUBE-programmet å kontrollere overflødighetsprosessen.

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-gruppe 1– Å legge til og fjerne denne kommandoen krever en ny lasting for at den oppdaterte konfigurasjonen skal tre i kraft. Vi laster inn plattformene på nytt etter at all konfigurasjon er tatt i bruk.

4

Konfigurer Gig1- og Gig2-grensesnittet med sine respektive virtuelle IP-er som vist nedenfor, og bruk redundant grensesnittidentifikator (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

Her er en forklaring på feltene som brukes i denne konfigurasjonen:

  • redundancy rii – Konfigurerer redundancy grensesnittidentifikator for redundancy-gruppen. Kreves for å generere en virtuell MAC-ADRESSE (VMAC). Den samme rii-ID-verdien må brukes på grensesnittet til hver ruter (ACTIVE/STANDBY) som har samme VIP.

    Hvis det finnes mer enn ett B2B-par på samme LAN, MÅ hvert par ha unike rii-ID-er på sine respektive grensesnitt (for å forhindre kollisjoner). Kommandoen vis overflødighetsprogramgruppe alle skal angi riktig lokal og motpartsinformasjon.

  • redundansgruppe 1– knytter grensesnittet til redundansgruppen som ble opprettet i trinn 2 ovenfor. Konfigurer RG-gruppen, samt VIP-en som er tilordnet dette fysiske grensesnittet.

    Det er obligatorisk å bruke et eget grensesnitt for redundans, det vil si at grensesnittet som brukes for taletrafikk ikke kan brukes som kontroll- og datagrensesnitt spesifisert i trinn 2 ovenfor. I dette eksemplet brukes Gigabit-grensesnitt 3 til RG-kontroll/data

5

Lagre konfigurasjonen av den første CUBE og last den inn på nytt.

Plattformen som skal lastes inn på nytt, er alltid Standby.

VCUBE-1#wr


                        Building configuration...
                      


                        [OK]
                      

VCUBE-1#reload


                        Proceed with reload? [confirm]

Når VCUBE-1 starter opp fullstendig, lagre konfigurasjonen av VCUBE-2 og last den inn på nytt.

VCUBE-2#wr


                        Building configuration...
                      


                        [OK]
                      

VCUBE-2#reload


                        Proceed with reload? [confirm]

6

Kontroller at boks-til-boks-konfigurasjonen fungerer som forventet. Relevant utdata er uthevet i fet skrift.

Vi lastet på nytt VCUBE-2 sist og i henhold til designhensyn. Plattformen som lastes på nytt vil alltid være Standby. 


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#

Fortsett deretter med konfigurasjonen av den lokale gatewayen (registreringsbasert eller sertifikatbasert) på begge HA CUBE-ene. Se Konfigurere lokal gateway på Cisco IOS XE for Webex Calling.