Grunnleggende

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 konsepter:

Konfigurasjonsretningslinjene i denne artikkelen forutsetter en dedikert lokal gatewayplattform uten eksisterende talekonfigurasjon. Hvis en eksisterende KUBE-bedriftsdistribusjon endres for også å bruke den lokale 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 sørge for at du overholder CUBE HA-designkravene.

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 kommandoer og logger i denne artikkelen er basert på minimum programvareutgivelse av Cisco IOS-XE 16.12.2 implementert på en vCUBE (CSR1000v).

Referansemateriale

Her er noen detaljerte KUBE HA konfigurasjonsveiledninger for ulike plattformer:

Oversikt over Webex-løsning for anrop

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

Local Gateway-distribusjonen (representert nedenfor) er fokus for denne artikkelen. Lokal gatewaystamme (lokalbasert PSTN) i Webex-anrop 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 media.

Figuren nedenfor viser en Webex Calling-distribusjon uten eksisterende IP PBX og gjelder for en enkelt eller en distribusjon på flere steder. Konfigurasjonen som er beskrevet 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/standby-par rutere. Dette paret deler den samme virtuelle IP-adressen (VIP) på tvers av sine respektive grensesnitt og utveksler kontinuerlig statusmeldinger. CUBE-øktinformasjon kontrolleres over de to ruterne, slik at standby-ruteren kan overta alt CUBE-samtalebehandlingsansvar umiddelbart hvis den aktive ruteren går ut av drift, noe som resulterer i tilstandsfull bevaring av signalering og media.

Kontrollpeking er begrenset til tilkoblede anrop med mediepakker. Samtaler i transitt er ikke kontrollpekt (for eksempel en prøvende eller ringende tilstand).

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

Fra og med IOS-XE 16.12.2 kan CUBE HA distribueres som en lokal gateway for Cisco Webex Calling trunk (Premises-based PSTN)-distribusjoner, 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-trunkdistribusjon.

Redundans gruppe Infra Komponent

Redundancy Group (RG) Infra-komponenten gir boks-til-boks kommunikasjonsinfrastrukturstøtte mellom de to CUBE-ene og forhandler om 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 signal- og medietilstanden for hvert anrop fra den aktive til standby-ruteren (via datagrensesnittet) – GigabitEthernet3 i figuren ovenfor.

  • Konfigurasjon og administrasjon av Virtual IP (VIP) grensesnitt for trafikken grensesnitt (flere trafikk grensesnitt kan konfigureres ved hjelp av samme RG gruppe) - GigabitEthernet 1 og 2 regnes trafikk grensesnitt.

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

Virtuell IP (VIP) adresseadministrasjon for både signalering og media

B2B HA er avhengig av VIP for å oppnå redundans. VIP-en og tilhørende fysiske grensesnitt 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 Access SBC, tjenesteleverandør eller proxy, bruker VIP som destinasjons-IP-adresse for samtalene som krysser gjennom CUBE HA-ruterne. Derfor, fra et Webex Calling-synspunkt, fungerer CUBE HA-parene som en enkelt lokal gateway.

Anropssignal- og RTP-øktinformasjonen for etablerte samtaler kontrolleres fra den aktive ruteren til standby-ruteren. Når den aktive ruteren går ned, tar standby-ruteren over og fortsetter å videresende RTP-strømmen som tidligere ble dirigert av den første ruteren.

Samtaler i forbigående tilstand på tidspunktet for failover vil ikke bli bevart etter overgangen. For eksempel kall som ikke er fullstendig etablert ennå, eller som er i ferd med å bli endret med en overførings- eller reservasjonsfunksjon. Etablerte samtaler kan kobles fra etter overgangen.

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

  • CUBE HA kan ikke ha TDM eller analoge grensesnitt samlokalisert

  • Gig1 og Gig2 er referert til som trafikk (SIP / RTP) grensesnitt og Gig3 er Redundancy Group (RG) Kontroll / data grensesnitt

  • Ikke mer enn 2 KUBE HA-par kan plasseres i samme lag 2-domene, ett med gruppe-ID 1 og det andre med gruppe-ID 2. Hvis konfigurering av 2 HA-par med samme gruppe-ID, må RG-kontroll-/datagrensesnitt tilhøre forskjellige lag 2-domener (vlan, separat bryter)

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

  • All signalering/media hentes fra/til den virtuelle IP-adressen

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

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

  • Redundans Interface Identifier, bør rii være unik for et par / grensesnitt kombinasjon på samme Layer 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 som bind, da de alltid er oppe

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

  • CUBE-HA støttes ikke over en crossover-kabelforbindelse for RG-kontroll/datalink (Gig3)

  • Begge plattformene må være identiske og være koblet til via en fysisk Switch på tvers av alle likeledes 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 terminert på CUBE direkte eller Data HA på hver side

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

  • Det er obligatorisk å bruke separat L3-grensesnitt for redundans (RG Control/data, Gig3). det vil si at grensesnitt som brukes til trafikk ikke kan brukes til HA-keepaliver og kontrollpunkter

  • Ved failover går den tidligere aktive KUBEN gjennom en omlasting ved design, og bevarer signalering og media

Konfigurer redundans på begge CUBE-ene

Du må konfigurere lag 2 boks-til-boks-redundans på begge CUBE-ene som er ment å 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 for å spore tilstanden til stemmetrafikkgrensesnittet, slik at den aktive ruten vil være en aktiv rolle etter at trafikkgrensesnittet er nede.
2

Konfigurer en RG for bruk med VoIP HA under programredundans-delmodusen.

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

  • programmeredundans– går inn i modus for programredundanskonfigurasjon

  • gruppe– går inn i konfigurasjonsmodus for redundansprogramgruppe

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

  • prioritet 100 failover-terskel 75– Angir startprioritet og failover-tersklene for et RG

  • tidtakere forsinkelse 30 reload 60-Konfigurererto ganger for forsinkelse og reload

    • Forsinkelsestimer som er tiden for å forsinke RG-gruppens initialisering og rolleforhandling etter at grensesnittet kommer opp - Standard 30 sekunder. Rekkevidden er 0-10000 sekunder

    • Last inn på nytt – Dette er tiden det tar å forsinke RG-gruppeinitialisering og rolleforhandling etter en omlasting – Standard 60 sekunder. Rekkevidden er 0-10000 sekunder

    • Standard tidtakere anbefales, selv om disse tidtakerne kan justeres for å imøtekomme eventuelle ekstra nettverkskonvergensforsinkelser som kan oppstå under oppstart / omlasting av ruterne, for å garantere at RG-protokollforhandling finner sted etter at ruting i nettverket har konvergert til et stabilt punkt. Hvis det for eksempel etter failover ser at det tar opptil 20 sekunder for den nye STANDBY-en å se den første RG HELLO-pakken fra den nye ACTIVE, bør tidtakerne justeres til 'timers forsinkelse 60 reload 120' for å ta hensyn til denne forsinkelsen.

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

  • data GigabitEthernet3– konfigurerer grensesnittet som brukes til kontrollpunktering av datatrafikk

  • spor– RG-gruppesporing av grensesnitt

  • protokoll 1– Angir protokollforekomsten som skal knyttes til et kontrollgrensesnitt, og går inn i konfigurasjonsmodus for redundansprogramprotokoll

  • timere hellotime 3 holdtime 10- Konfigurerer de to tidtakerne for hellotime og holdtime:

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

    • Holdtime – Intervallet mellom mottak av en Hello-melding og antagelsen om at avsenderruteren har mislyktes. Denne varigheten må være større enn hello-time - Standard 10 sekunder. Rekkevidden er 750 millisekunder-255 sekunder

      Vi anbefaler at du konfigurerer tidtakeren til å være minst 3 ganger verdien av hellotime-timeren.
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-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 omstart for at den oppdaterte konfigurasjonen skal tre i kraft. Vi laster inn plattformene på nytt etter at all konfigurasjonen er brukt.
4

Konfigurer Grensesnittene Gig1 og Gig2 med deres respektive virtuelle IP-adresser som vist nedenfor, og bruk redundansgrensesnittidentifikatoren (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 redundansgrensesnittidentifikatoren for redundansgruppen. Kreves for å generere en Virtual MAC -adresse (VMAC). Den samme RII ID-verdien må brukes på grensesnittet til hver ruter (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 søknadsgruppe alle' skal angi riktig lokal og peer informasjon.

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


     

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

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

Plattformen for å laste sist er alltid standby.

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

Etter at VCUBE-1 har startet opp helt, lagre konfigurasjonen av VCUBE-2 og last den 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. Relevante utdata utheves med fet skrift.

Vi lastet VCUBE-2 sist, og i henhold til designhensynene vil plattformen for å laste sist 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#

Konfigurer en lokal gateway på begge CUBE-ene

I eksempelkonfigurasjonen bruker vi følgende trunkinformasjon fra Control Hub til å bygge local 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 den kan brukes i legitimasjonen eller 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 Local Gateway-konfigurasjonen som vil gjelde for begge plattformene basert på Control Hub-parameterne som vises ovenfor, lagre og last inn på nytt. SIP Digest-legitimasjon fra Control Hub er uthevet med 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

For å vise vis kommandoutgangen har vi lastet VCUBE-2 på nytt etterfulgt av VCUBE-1, noe som gjør VCUBE-1 til standby CUBE og VCUBE-2 til den aktive KUBEN
2

Til enhver tid vil bare én plattform opprettholde en aktiv registrering som lokal gateway med Webex Calling Access SBC. Ta en titt på utdataene fra følgende showkommandoer.

vis redundans søknadsgruppe 1

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

Fra utgangen ovenfor kan du se at VCUBE-2 er den aktive LGW som opprettholder registreringen med Webex Calling access SBC, mens utdataene fra "show sip-ua registerstatus" er tomme 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 å utstede følgende kommando på den aktive LGW, VCUBE-2 i dette tilfellet.


VCUBE-2#redundancy application reload group 1 self

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

  • Når ACTIVE-ruteren lastes inn på nytt

  • Når den AKTIVE ruteren slås av og på

  • Når et RG-konfigurert grensesnitt for ACTIVE-ruteren slås av, er sporing aktivert for
5

Sjekk om VCUBE-1 har registrert seg hos Webex Calling Access SBC. VCUBE-2 ville ha reloaded 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