Grunnleggende informasjon

Forutsetninger

Før du distribuerer CUBE HA som en lokal gateway for Webex Calling, må du sørge for at du har en grundig forståelse av følgende begreper:

Konfigurasjonsretningslinjene i denne artikkelen forutsetter en dedikert lokal gateway plattform uten eksisterende talekonfigurasjon. Hvis en eksisterende CUBE-bedriftsdistribusjon endres til også å bruke den lokal gateway -funksjonen for Cisco Webex Calling, må du følge nøye med på konfigurasjonen som brukes for å sikre at eksisterende samtaleflyter og funksjoner ikke avbrytes, og at du overholder designkravene for CUBE HA .

Maskinvare og programvarekomponenter

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

Vis-kommandoene og loggene i denne artikkelen er basert på minste programvareutgivelse av Cisco IOS-XE 16.12.2 implementert på en vCUBE (CSR1000v).

Referansemateriale

Her er noen detaljerte CUBE HA-konfigurasjonsveiledninger for forskjellige plattformer:

Oversikt over Webex Calling Solution

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

Den lokale gateway-distribusjonen (representert nedenfor) er fokuset i denne artikkelen. Lokal gateway-trunk (lokalbasert PSTN) 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.

Figuren nedenfor viser en Webex Calling distribusjon uten eksisterende IP-PBX, og gjelder for én distribusjon eller en distribusjon med flere nettsteder. Konfigurasjonen som er skissert i denne artikkelen, er basert på denne distribusjonen.

Lag 2 Boks-til-boks-redundans

CUBE HA lag 2 boks-til-boks-redundans bruker infrastrukturprotokollen Redundancy Group (RG) til å danne et aktivt ruterepar/ventemoduspar. Dette paret deler den samme virtuelle IP-adresse (VIP) på tvers av sine respektive grensesnitt og utveksler kontinuerlig statusmeldinger. CUBE-øktinformasjonen kontrolleres på tvers av ruterparet, noe som gjør at standby-ruteren kan overta alt CUBE samtalebehandling umiddelbart hvis den aktive ruteren går ut av drift, noe som resulterer i tilstandsmessig bevaring av signalisering og medier.

Kontrollpeking er begrenset til tilkoblede samtaler med mediepakker. Samtaler under overføring er ikke kontrollerte (for eksempel prøve- eller ringestatus).

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

Fra og med IOS-XE 16.12.2 kan CUBE HA distribueres som en lokal gateway for Cisco Webex Calling -trunk-distribusjoner (lokalbasert PSTN), og vi vil dekke utformingshensyn og konfigurasjoner i denne artikkelen. Denne figuren viser et typisk CUBE HA-oppsett som lokal gateway for en Cisco Webex Calling .

Infrakomponent for redundansgruppe

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

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

  • En transportmekanisme for kontroll av signalisering og medietilstand for hver samtale fra den aktive ruteren til standby-ruteren (via datagrensesnittet) – GigabitEthernet3 i figuren ovenfor.

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

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

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

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

Samtalesignalerings- og RTP-øktinformasjonen for etablerte anrop kontrolleres fra den aktive ruteren til standby-ruteren. Når den aktive ruteren går ned, tar ventemodus-ruteren over, og fortsetter å videresende RTP-strøm som tidligere ble rutet av den første ruteren.

Anrop i forbigående tilstand på tidspunktet for failover vil ikke bli bevart etter byttet. For eksempel anrop som ikke er fullstendig etablert ennå, eller som er i ferd med å bli endret med en overførings- eller ventingsfunksjon. Etablerte samtaler kan bli koblet fra etter byttet.

Følgende krav finnes for å bruke CUBE HA som en lokal gateway for tilstandsfull failover for samtaler:

  • CUBE HA kan ikke ha TDM eller analoge grensesnitt samlokalisert

  • Gig1 og Gig2 omtales som trafikkgrensesnitt (SIP/RTP), og Gig3 er grensesnitt for kontroll/data for redundansgruppe (RG)

  • Ikke mer enn 2 CUBE HA-par kan plasseres i det samme lag 2-domenet, ett med gruppe-id 1 og det andre med gruppe-id 2. Hvis du konfigurerer to HA-par med samme gruppe-ID, må RG Control/Data-grensesnitt tilhøre forskjellige lag 2-domener (vlan, egen svitsj)

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

  • All signalisering/medier hentes fra/til den virtuelle IP-adressen

  • Hver gang en plattform lastes inn på nytt i et CUBE-HA-forhold, starter den alltid opp som ventemodus

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

  • Redundansgrensesnittidentifikator, rii må være unik for en par/grensesnittkombinasjon på samme lag 2

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

  • Loopback-grensesnitt kan ikke brukes som binding da de alltid er oppe

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

  • CUBE-HA støttes ikke via en krysset kabeltilkobling for RG-control/datalink (Gig3)

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

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

  • Både Aktiv/Standby må være i samme datasenter

  • Det er obligatorisk å bruke eget L3-grensesnitt for redundans (RG Control/data, Gig3). dvs. grensesnitt som brukes for trafikk, kan ikke brukes til HA keepalives og sjekkpunkter

  • Ved failover går den tidligere aktive CUBE gjennom en designmessig ny innlasting, noe som bevarer signalisering og medier

Konfigurer redundans på begge CUBE-ene

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

1

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

konf t spor 1 grensesnitt GigabitEthernet1 linjeprotokoll spor 2 grensesnitt GigabitEthernet2 linjeprotokoll avslutt 

VCUBE-1#conf t

VCUBE-1(config)# spor 1-grensesnitt GigabitEthernet1-linjeprotokoll

VCUBE-1(config-track)# spor 2-grensesnitt GigabitEthernet2-linjeprotokoll

VCUBE-1(config-track)# avslutte

VCUBE-2#conf t

VCUBE-2(config)# spor 1-grensesnitt GigabitEthernet1-linjeprotokoll

VCUBE-2(config-track)# spor 2-grensesnitt GigabitEthernet2-linjeprotokoll

VCUBE-2(config-track)# avslutte

Spor CLI brukes i RG til å spore tilstanden for taletrafikk , slik at den aktive ruten får ganske sin aktive rolle etter at trafikkgrensesnittet er nede.

2

Konfigurer en RG for bruk med VoIP HA i undermodusen for programmets redundans.

redundans program redundans gruppe 1 navn LocalGateway-HA prioritet 100 failover terskel 75 kontroll GigabitEthernet3 protokoll 1 data GigabitEthernet3 tidtakere forsinkelse 30 reload 60 spor 1 avslutning spor 2 avslutning avslutt protokoll 1 tidtakere hellotime 3 holdtime exit exit 

VCUBE-1(config)# redundans

VCUBE-1(config-red)# programoverflødighet

VCUBE-1(config-red-app)# gruppe 1

VCUBE-1(config-red-app-grp)# gi navnet LocalGateway-HA

VCUBE-1(config-red-app-grp)# terskel for failover for prioritet 100 75

VCUBE-1(config-red-app-grp)# kontrollere GigabitEthernet3-protokollen 1

VCUBE-1(config-red-app-grp)# data GigabitEthernet3

VCUBE-1(config-red-app-grp)# tidtakere forsinkelse 30 reload 60

VCUBE-1(config-red-app-grp)# avslutning av spor 1

VCUBE-1(config-red-app-grp)# avslutning av spor 2

VCUBE-1(config-red-app-grp)# avslutte

VCUBE-1(config-red-app)# protokoll 1

VCUBE-1(config-red-app-prtcl)# tidtakere hellotime 3 holdetid 10

VCUBE-1(config-red-app-prtcl)# avslutte

VCUBE-1(config-red-app)# avslutte

VCUBE-1(config-red)# avslutte

VCUBE-1(config)#

VCUBE-2(config)# redundans

VCUBE-2(config-red)# programoverflødighet

VCUBE-2(config-red-app)# gruppe 1

VCUBE-2(config-red-app-grp)# gi navnet LocalGateway-HA

VCUBE-2(config-red-app-grp)# terskel for failover for prioritet 100 75

VCUBE-2(config-red-app-grp)# kontrollere GigabitEthernet3-protokollen 1

VCUBE-1(config-red-app-grp)# data GigabitEthernet3

VCUBE-2(config-red-app-grp)# tidtakere forsinkelse 30 reload 60

VCUBE-2(config-red-app-grp)# avslutning av spor 1

VCUBE-2(config-red-app-grp)# avslutning av spor 2

VCUBE-2(config-red-app-grp)# avslutte

VCUBE-2(config-red-app)# protokoll 1

VCUBE-2(config-red-app-prtcl)# tidtakere hellotime 3 holdetid 10

VCUBE-2(config-red-app-prtcl)# avslutte

VCUBE-2(config-red-app)# avslutte

VCUBE-2(config-red)# avslutte

VCUBE-2(config)#

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

  • redundans – Går inn i redundansmodus

  • programoverflødighet – Går inn i konfigurasjonsmodus for programredundans

  • gruppe – Går inn i konfigurasjonsmodus for redundans for programgruppe

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

  • terskel for failover for prioritet 100 75 – Angir startprioritet og failoverterskler for en RG

  • tidtakere forsinkelse 30 reload 60 – Konfigurerer de to tidspunktene for forsinkelse og innlasting på nytt

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

    • Last inn på nytt – Dette er tiden det tar å forsinke initialisering av RG-gruppe og rolleforhandling etter en ny innlasting – standard 60 sekunder. Området er 0–10000 sekunder

    • Standard tidtakere anbefales, selv om disse tidtakerne kan justeres for å imøtekomme ytterligere nettverkskonvergensforsinkelser som kan oppstå under oppstart/på nytt innlasting av ruterne, for å garantere at RG-protokollforhandlingen finner sted etter at rutingen i nettverket har konvergert til en stabil punkt. Hvis det for eksempel etter failover vises at det tar opptil 20 sek før den nye STANDBY-en ser den første RG HELLO-pakken fra den nye ACTIVE, bør tidtakerne justeres til «timere delay 60 reload 120» for å ta hensyn til dette forsinkelse.

  • kontrollere GigabitEthernet3-protokollen 1 – Konfigurerer grensesnittet som brukes til å utveksle keepalive- og hello-meldinger mellom de to CUBE-ene, og angir protokollforekomsten som skal kobles til et kontrollgrensesnitt og gå inn i konfigurasjonsmodus for redundans applikasjonsprotokoll

  • data GigabitEthernet3 – Konfigurerer grensesnittet som brukes til sjekkpunkt for datatrafikk

  • spor —RG gruppesporing av grensesnitt

  • protokoll 1 – Angir protokollforekomsten som skal kobles til et kontrollgrensesnitt og går inn i konfigurasjonsmodus for redundans applikasjonsprotokoll

  • tidtakere hellotime 3 holdetid 10 – Konfigurerer de to tidtakerne for hellotime og ventetid:

    • 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 avsenderruteren 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 holdetid-tidtakeren til å være minst 3 ganger verdien av hellotime-tidtakeren.

3

Aktiver boks-til-boks-redundans for CUBE-applikasjonen. Konfigurer RG fra forrige trinn under taletjeneste VoIP . Dette gjør det mulig for CUBE-applikasjonen å kontrollere redundansprosessen.

taletjeneste VoIP-redundans-gruppe 1 avslutt

VCUBE-1(config)# taletjeneste VoIP

VCUBE-1(config-voi-serv)# redundansgruppe 1

 % Opprettet RG 1-tilknytning til Voice B2B HA; Last inn ruteren på nytt for at den nye konfigurasjonen skal tre i kraft 

VCUBE-1(config-voi-serv)# avslutte

VCUBE-2(config)# taletjeneste VoIP

VCUBE-2(config-voi-serv)# redundansgruppe 1

 % Opprettet RG 1-tilknytning til Voice B2B HA; Last inn ruteren på nytt for at den nye konfigurasjonen skal tre i kraft 

VCUBE-2(config-voi-serv)# avslutte

redundansgruppe 1 – Å legge til og fjerne denne kommandoen krever en ny innlasting 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-grensesnittene med sine respektive virtuelle IP-er som vist nedenfor, og bruk ID-en for redundansgrensesnitt ( rii )

VCUBE-1(config)# grensesnitt GigabitEthernet1

VCUBE-1(config-if)# redundans rii 1

VCUBE-1(config-if)# redundansgruppe 1 eksklusiv ip 198.18.1.228

VCUBE-1(config-if)# avslutte

VCUBE-1(config)#

VCUBE-1(config)# grensesnitt GigabitEthernet2

VCUBE-1(config-if)# redundans rii 2

VCUBE-1(config-if)# redundansgruppe 1 eksklusiv ip 198.18.133.228

VCUBE-1(config-if)# avslutte

VCUBE-2(config)# grensesnitt GigabitEthernet1

VCUBE-2(config-if)# redundans rii 1

VCUBE-2(config-if)# redundansgruppe 1 eksklusiv ip 198.18.1.228

VCUBE-2(config-if)# avslutte

VCUBE-2(config)#

VCUBE-2(config)# grensesnitt GigabitEthernet2

VCUBE-2(config-if)# redundans rii 2

VCUBE-2(config-if)# redundansgruppe 1 eksklusiv ip 198.18.133.228

VCUBE-v(config-if)# avslutte

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

  • redundans rii – Konfigurerer ID-en for redundansgrensesnittet for redundansgruppen. Kreves for å generere en virtuell MAC-adresse (VMAC). Den samme rii ID-verdien må brukes på grensesnittet til hver rutere (ACTIVE/STANDBY) som har samme VIP.

    Hvis det er mer enn ett B2B-par på samme LAN, MÅ hvert par ha unike rii-ID-er på sine respektive grensesnitt (for å forhindre kollisjon). «vis redundans programgruppe alle» skal indikere riktig lokal informasjon og nodeinformasjon.

  • redundansgruppe 1 – Knytter grensesnittet til redundansgruppen som ble opprettet i trinn 2 ovenfor. Konfigurer RG-gruppen, i tillegg til 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 angitt i trinn 2 ovenfor. I dette eksemplet brukes Gigabit-grensesnitt 3 for RG-kontroll/data

5

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

Plattformen som skal lastes inn sist, er alltid ventemodus.

VCUBE-1# wr

 Konfigurasjon av bygning … 

 [OK] 

VCUBE-1# laste inn på nytt

 Fortsette med å laste inn på nytt? [bekreft]

Etter VCUBE-1 starter opp fullstendig, lagre konfigurasjonen for VCUBE-2 og last den inn på nytt.

VCUBE-2# wr

 Konfigurasjon av bygning … 

 [OK] 

VCUBE-2# laste inn på nytt

 Proceed with reload? [confirm]

6

Verify that the box-to-box configuration is working as expected. Relevant output is highlighted in bold.

We reloaded VCUBE-2 last and as per the design considerations; the platform to reload last will always be 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#

Configure a Local Gateway on Both CUBEs

In our example configuration, we’re using the following trunk information from Control Hub to build the Local Gateway configuration on both the platforms, VCUBE-1 and VCUBE-2. The username and password for this setup are as follows:

  • Username: Hussain1076_LGU

  • Password: lOV12MEaZx

1

Ensure that a configuration key is created for the password, with the commands shown below, before it can be used in the credentials or shared secrets. Type 6 passwords are encrypted using AES cipher and this user-defined configuration key. 

 LocalGateway#conf t LocalGateway(config)#key config-key password-encrypt Password123 LocalGateway(config)#password encryption aes

Here is the Local Gateway configuration that will apply to both platforms based on the Control Hub parameters displayed above, save and reload. SIP Digest credentials from Control Hub are highlighted in bold.

 configure terminal crypto pki trustpoint dummyTp revocation-check crl exit sip-ua crypto signaling default trustpoint dummyTp cn-san-validate server transport tcp tls v1.2 end configure terminal crypto pki trustpool import clean url http://www.cisco.com/security/pki/trs/ios_core.p7b end configure terminal voice service voip ip address trusted list ipv4 x.x.x.x y.y.y.y exit allow-connections sip to sip media statistics media bulk-stats no supplementary-service sip refer no supplementary-service sip handle-replaces fax protocol pass-through g711ulaw stun stun flowdata agent-id 1 boot-count 4 stun flowdata shared-secret 0 Password123! sip g729 annexb-all early-offer forced end configure terminal voice class sip-profiles 200 rule 9 request ANY sip-header SIP-Req-URI modify "sips:(.*)" "sip:\1" rule 10 request ANY sip-header To modify "<sips:(.*)" "<sip:\1" rule 11 request ANY sip-header From modify "<sips:(.*)" "<sip:\1" rule 12 request ANY sip-header Contact modify "<sips:(.*)>" "<sip:\1;transport=tls>" rule 13 response ANY sip-header To modify "<sips:(.*)" "<sip:\1" rule 14 response ANY sip-header From modify "<sips:(.*)" "<sip:\1" rule 15 response ANY sip-header Contact modify "<sips:(.*)" "<sip:\1" rule 20 request ANY sip-header From modify ">" ";otg=hussain1076_lgu>" rule 30 request ANY sip-header P-Asserted-Identity modify "sips:(.*)" "sip:\1" voice class codec 99 codec preference 1 g711ulaw codec preference 2 g711ulaw exit voice class srtp-crypto 200 crypto 1 AES_CM_128_HMAC_SHA1_80 exit voice class stun-usage 200 stun usage firewall-traversal flowdata exit voice class tenant 200 registrar dns:40462196.cisco-bcld.com scheme sips expires 240 refresh-ratio 50 tcp tls credentials number Hussain5091_LGU username Hussain1076_LGU password 0 lOV12MEaZx realm Broadworks authentication username Hussain5091_LGU password 0 lOV12MEaZx realm BroadWorks authentication username Hussain5091_LGU password 0 lOV12MEaZx realm 40462196.cisco-bcld.com no remote-party-id sip-server dns:40462196.cisco-bcld.com connection-reuse srtp-crypto 200 session transport tcp tls url sips error-passthru asserted-id pai bind control source-interface GigabitEthernet1 bind media source-interface GigabitEthernet1 no pass-thru content custom-sdp sip-profiles 200 outbound-proxy dns:la01.sipconnect-us10.cisco-bcld.com privacy-policy passthru voice class tenant 100 session transport udp url sip error-passthru bind control source-interface GigabitEthernet2 bind media source-interface GigabitEthernet2 no pass-thru content custom-sdp voice class tenant 300 bind control source-interface GigabitEthernet2 bind media source-interface GigabitEthernet2 no pass-thru content custom-sdp voice class uri 100 sip host ipv4:198.18.133.3 voice class uri 200 sip pattern dtg=hussain1076.lgu dial-peer voice 101 voip description Outgoing dial-peer to IP PSTN destination-pattern BAD.BAD session protocol sipv2 session target ipv4:198.18.133.3 voice-class codec 99 voice-class sip tenant 100 dtmf-relay rtp-nte no vad dial-peer voice 201 voip description Outgoing dial-peer to Webex Calling destination-pattern BAD.BAD session protocol sipv2 session target sip-server voice-class codec 99 voice-class stun-usage 200 no voice-class sip localhost voice-class sip tenant 200 dtmf-relay rtp-nte srtp no vad voice class dpg 100 description Incoming WebexCalling(DP200) to IP PSTN(DP101) dial-peer 101 preference 1 voice class dpg 200 description Incoming IP PSTN(DP100) to Webex Calling(DP201) dial-peer 201 preference 1 dial-peer voice 100 voip desription Incoming dial-peer from IP PSTN session protocol sipv2 destination dpg 200 incoming uri via 100 voice-class codec 99 voice-class sip tenant 300 dtmf-relay rtp-nte no vad dial-peer voice 200 voip description Incoming dial-peer from Webex Calling session protocol sipv2 destination dpg 100 incoming uri request 200 voice-class codec 99 voice-class stun-usage 200 voice-class sip tenant 200 dtmf-relay rtp-nte srtp no vad end copy run start

To display the show command output, we've reloaded VCUBE-2 followed by VCUBE-1, making VCUBE-1 the standby CUBE and VCUBE-2 the active CUBE

2

At any given time, only one platform will maintain an active registration as the Local Gateway with the Webex Calling access SBC. Take a look at the output of the following show commands.

show redundancy application group 1

show sip-ua register status 

 VCUBE-1#show redundancy application group 1 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: STANDBY HOT Peer RF state: ACTIVE VCUBE-1#show sip-ua register status VCUBE-1#

 VCUBE-2#show redundancy application group 1 Group ID:1 Group Name:LocalGateway-HA Administrative State: No Shutdown Aggregate operational state : Up My Role: ACTIVE Peer Role: STATUS Peer Presence: Yes Peer Comm: Yes Peer Progression Started: Yes RF Domain: btob-one RF state: ACTIVE Peer RF state: STANDBY HOT VCUBE-2#show sip-ua register status Tenant: 200 --------------------Registrar-Index  1 --------------------- Line peer expires(sec) reg survival P-Associ-URI ============================== ========== ============ === ======== ============ Hussain5091_LGU -1 48 yes normal VCUBE-2#

From the output above, you can see that VCUBE-2 is the active LGW maintaining the registration with Webex Calling access SBC, whereas the output of the “show sip-ua register status” is blank in VCUBE-1

3

Now enable the following debugs on VCUBE-1

 VCUBE-1#debug ccsip non-call SIP Out-of-Dialog tracing is enabled VCUBE-1#debug ccsip info SIP Call info tracing is enabled VCUBE-1#debug ccsip message

4

Simulate failover by issuing the following command on the active LGW, VCUBE-2 in this case.

 VCUBE-2#redundancy application reload group 1 self

Switchover from the ACTIVE to the STANDBY LGW occurs in the following scenario as well besides the CLI listed above

  • When the ACTIVE router reloads

  • When the ACTIVE router power cycles

  • When any RG configured interface of the ACTIVE router is shutdown for which tracking is enabled

5

Check to see if VCUBE-1 has registered with Webex Calling access SBC. VCUBE-2 would have reloaded by now.

 VCUBE-1#show sip-ua register status Tenant: 200 --------------------Registrar-Index  1 --------------------- Line peer expires(sec) reg survival P-Associ-URI ============================== ========== ============ === ======== ============ Hussain5091_LGU -1 56 yes normal VCUBE-1#

VCUBE-1 is now the active LGW.

6

Look at the relevant debug log on VCUBE-1 sending a SIP REGISTER to Webex Calling VIA the virtual IP and receiving a 200 OK.

 VCUBE-1#show log Jan 9 18:37:24.769: %RG_MEDIA-3-TIMEREXPIRED: RG id 1 Hello Time Expired. Jan 9 18:37:24.771: %RG_PROTCOL-5-ROLECHANGE: RG id 1 role change from Standby to Active Jan 9 18:37:24.783: %VOICE_HA-2-SWITCHOVER_IND: SWITCHOVER, from STANDBY_HOT to ACTIVE state. Jan 9 18:37:24.783: //-1/xxxxxxxxxxxx/SIP/Info/info/4096/sip_ha_notify_active_role_event: Received notify active role event Jan 9 18:37:25.758: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Sent: REGISTER sip: 40462196.cisco-bcld.com:5061 SIP/2.0 Via: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK0374 From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com> Date: Thu, 09 Jan 2020 18:37:24 GMT Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 User-Agent: Cisco-SIPGateway/IOS-16.12.02 Max-Forwards: 70 Timestamp: 1578595044 CSeq: 2 REGISTER Contact: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls> Expires: 240 Supported: path Content-Length: 0 

Jan 9 18:37:25.995: //-1/000000000000/SIP/Msg/ccsipDisplayMsg: Received: SIP/2.0 401 Unauthorized Via: SIP/2.0/TLS 198.18.1.228:5061;received=173.38.218.1;branch=z9hG4bK0374;rport=4742 From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1324701502-1578595045969 Date: Thu, 09 Jan 2020 18:37:24 GMT Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 Timestamp: 1578595044 CSeq: 2 REGISTER WWW-Authenticate; DIGEST realm="BroadWorks",qop="auth",nonce="BroadWorksXk572qd01Ti58zliBW",algorithm=MD5 Content-Length: 0 

Jan 9 18:37:26.000: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Sent: REGISTER sip:40462196.cisco-bcld.com:5061 SIP/2.0 Via: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK16DC From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com> Date: Thu, 09 Jan 2020 18:37:25 GMT Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 User-Agent:Cisco-SIPGateway/IOS-16.12.02 Max-Forwards: 70 Timestamp: 1578595045 CSeq: 3 REGISTER Contact: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls> Expires: 240 Supported: path Authorization: Digest username="Hussain1076_LGU",realm="BroadWorks",uri="sips:40462196.cisco-bcld.com:5061",response="b6145274056437b9c07f7ecc08ebdb02",nonce="BroadWorksXk572qd01Ti58z1iBW",cnonce="3E0E2C4D",qop=auth,algorithm=MD5,nc=00000001 Content-Length: 0 

Jan 9 18:37:26.190: //1/000000000000/SIP/Msg/ccsipDisplayMsg:  Received: SIP/2.0 200 OK Via: SIP/2.0/TLS 198.18.1.228:5061;received=173.38.218.1;branch=z9hG4bK16DC;rport=4742 From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1897486570-1578595-46184 Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 Timestamp: 1578595045 CSeq: 3 REGISTER Contact: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>;expires=120;q=0.5 Allow-Events: call-info,line-seize,dialog,message-summary,as-feature-event,x-broadworks-hoteling,x-broadworks-call-center-status,conference Content-Length: 0