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.

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

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.

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 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 voice service voip. Dette gjør det mulig for CUBE-applikasjonen å kontrollere redundansprosessen. 

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

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

  • 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


                        Building configuration...
                      


                        [OK]
                      

VCUBE-1#reload


                        Proceed with reload? [confirm]

Etter VCUBE-1 starter opp fullstendig, lagre konfigurasjonen for 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 inn på nytt VCUBE-2 sist og i henhold til utformingshensyn; plattformen som skal lastes inn på nytt, vil alltid være det Ventemodus .


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#

Konfigurere en lokal gateway på begge CUBE-ene

I eksempelkonfigurasjonen vår bruker vi følgende trunkinformasjon fra Control Hub til å bygge den lokale gateway-konfigurasjonen på begge plattformene, VCUBE-1 og VCUBE-2. Brukernavnet og passordet for dette oppsettet er som følger:

  • Brukernavn: Hussain1076_ LGU

  • Passord: lOV12MEaZx

1

Kontroller at det opprettes en konfigurasjonsnøkkel for passordet, med kommandoene vist nedenfor, før det kan brukes i legitimasjonen eller i delte hemmeligheter. Type 6-passord krypteres ved hjelp av AES-kryptering og denne brukerdefinerte konfigurasjonsnøkkelen.


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

Her er den lokale gateway-konfigurasjonen som gjelder for begge plattformene basert på Control Hub-parametrene vist ovenfor, lagre og last inn på nytt. SIP sammendragslegitimasjon fra Control Hub er uthevet i fet skrift .


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

Vi har lastet inn på nytt for å vise kommandoen show VCUBE-2 etterfulgt av VCUBE-1 , gjør VCUBE-1 ventemodus CUBE og VCUBE-2 den aktive CUBE

2

Til enhver tid vil bare én plattform opprettholde en aktiv registrering som lokal gateway med SBC for Webex Calling tilgang. Ta en titt på resultatet av følgende show-kommandoer.

vis redundans-programgruppe 1

vis sip-ua-registerstatus


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#

Fra utdataene ovenfor kan du se det VCUBE-2 er den aktive LGW-en som opprettholder registreringen med SBC for Webex Calling tilgang, mens utdataene for «vis sip-ua-registerstatus» er tom i VCUBE-1

3

Aktiver nå følgende feilsøkingsprogrammer på 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

Simuler failover ved å gi følgende kommando på den aktive LGW-en, i dette tilfellet VCUBE-2.


VCUBE-2#redundancy application reload group 1 self

Overgang fra ACTIVE til STANDBY LGW skjer i følgende scenario i tillegg til CLI-en som er oppført ovenfor

  • Når den AKTIVE ruteren lastes inn på nytt

  • Når den AKTIVE ruteren slås av

  • Når et hvilket som helst RG-konfigurert grensesnitt for ACTIVE-ruteren avsluttes som sporing er aktivert for

5

Kontroller om VCUBE-1 er registrert med Webex Calling -tilgang SBC. VCUBE-2 ville ha blitt lastet inn på nytt nå.


              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 er nå den aktive LGW.

6

Se på den relevante feilsøkingsloggen på VCUBE-1 som sender et SIP-REGISTER til Webex Calling VIA den virtuelle IP-en og mottar en 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