Grunnleggende

Forutsetninger

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

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

Maskinvare- og programvarekomponenter

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

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

Referansemateriale

Her er noen detaljerte CUBE HA konfigurasjonsveiledninger for ulike plattformer:

Oversikt over Webex Calling-løsning

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

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

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

Lag 2 boks-til-boks-redundans

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

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

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

Fra og med IOS-XE 16.12.2 KAN CUBE HA distribueres som lokal gateway for Cisco Webex Calling-trunk-distribusjoner (lokalt basert PSTN), og vi dekker designhensyn og konfigurasjoner i denne artikkelen. Denne figuren viser et typisk CUBE HA-oppsett som lokal gateway for en Cisco Webex Calling-trunkdistribusjon.

Redundancy-gruppe infra-komponent

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Konfigurere redundans på begge CUBE-ene

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

1

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

konf t spor 1 grensesnitt GigabitEthernet1 line-protocol spor 2 grensesnitt GigabitEthernet2 line-protocol utgang 

VCUBE-1#konf t

VCUBE-1(config)#spor 1 grensesnitt GigabitEthernet1 line-protocol

VCUBE-1(config-track)#track 2-grensesnitt GigabitEthernet2 line-protocol

VCUBE-1(config-track)#utgang

VCUBE-2#konf t

VCUBE-2(config)#spor 1 grensesnitt GigabitEthernet1 line-protocol

VCUBE-2(config-track)#track 2-grensesnitt GigabitEthernet2 line-protocol

VCUBE-2(config-track)#utgang

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

2

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

redundans program redundans gruppe 1 navn LocalGateway-HA prioritet 100 failover-terskel 75 kontroll GigabitEthernet3 protokoll 1 data GigabitEthernet3 timers forsinkelse 30 omlasting 60 spor 1 nedleggingsspor 2 nedleggingsavslutningsprotokoll 1 timers hellotid 3 holdtid 10 utgang utgang utgang 

VCUBE-1(config)#redundans

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

VCUBE-1(config-rød-app)#gruppe 1

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

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

VCUBE-1(config-red-app-grp)#control GigabitEthernet3-protokoll 1

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

VCUBE-1(config-red-app-grp)#timers forsinkelse 30 omlasting 60

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

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

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

VCUBE-1(config-rød-app)#protokoll 1

VCUBE-1(config-red-app-prtcl)#timer heltid 3 holdtid 10

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

VCUBE-1(config-rød-app)#utgang

VCUBE-1(config-rød)#utgang

VCUBE-1(config)#

VCUBE-2(config)#redundans

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

VCUBE-2(config-rød-app)#gruppe 1

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

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

VCUBE-2(config-red-app-grp)#control GigabitEthernet3-protokoll 1

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

VCUBE-2(config-red-app-grp)#timers forsinkelse 30 omlasting 60

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

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

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

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

VCUBE-2(config-red-app-prtcl)#timer heltid 3 holdtid 10

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

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

VCUBE-2(config-rød)#utgang

VCUBE-2(config)#

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

  • redundans– går inn i redundans-modus

  • Applikasjonsredundans– Går inn i konfigurasjonsmodus for applikasjonsredundans

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

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

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

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

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

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

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

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

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

  • sporing– RG-gruppesporing av grensesnitt

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

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

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

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

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

3

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

taletjeneste voip redundans gruppe 1 utgang

VCUBE-1(config)#taletjeneste voip

VCUBE-1(config-voi-serv)#redundancy-gruppe 1

 % Created RG 1 association with Voice B2B HA; last inn ruteren på nytt for at den nye konfigurasjonen skal tre i kraft 

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

VCUBE-2(config)#taletjeneste voip

VCUBE-2(config-voi-serv)#redundancy-gruppe 1

 % Created RG 1 association with Voice B2B HA; last inn ruteren på nytt for at den nye konfigurasjonen skal tre i kraft 

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

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

4

Konfigurer Gig1- og Gig2-grensesnittet med sine respektive virtuelle IP-er som vist nedenfor, og bruk redundant grensesnittidentifikator (rii)

VCUBE-1(config)#grensesnitt for GigabitEthernet1

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

VCUBE-1(config-if)# redundans gruppe 1 ip 198.18.1.228 eksklusiv

VCUBE-1(config-if)# utgang

VCUBE-1(config)#

VCUBE-1(config)#grensesnitt for GigabitEthernet2

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

VCUBE-1(config-if)# redundans gruppe 1 ip 198.18.133.228 eksklusiv

VCUBE-1(config-if)# utgang

VCUBE-2(config)#grensesnitt for GigabitEthernet1

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

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

VCUBE-2(config-if)# utgang

VCUBE-2(config)#

VCUBE-2(config)#grensesnitt for GigabitEthernet2

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

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

VCUBE-v(config-if)# utgang

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

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

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

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

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

5

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

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

VCUBE-1#wr

 Byggkonfigurasjon... 

 [ok] 

VCUBE-1#last inn på nytt

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

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

VCUBE-2#wr

 Byggkonfigurasjon... 

 [ok] 

VCUBE-2#last inn på nytt

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

6

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

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

 VCUBE-1#vis overflødighetsapplikasjonsgruppe alle Feil angir gruppe 1-informasjon:        Kjøretidsprioritet: [100] RG feil RG-tilstand: Opp.                        Totalt antall svitsjer på grunn av feil:  0 Totalt antall endringer ned/opp på grunn av feil: 0 Gruppe-ID:1 Gruppenavn:LocalGateway-HA Administrativ tilstand: Ingen driftstilstand for nedlukningsaggregat: Opp  Min rolle: AKTIV noderolle: STANDBY Peer Presence: Ja motpartskomma: Ja Peer-progresjon startet: Ja RF-domene: btob-én RF-tilstand: RF-status for AKTIV node: STANDBY HOT RG Protocol RG 1 ------------------ Rolle: Aktiv forhandling: Aktivert prioritet: 100 Protokolltilstand: Aktiv(e) Ctrl Intf-tilstand: Opp aktiv motpart: Lokal ventemotpart: adresse 10.1.1.2, prioritet 100, intf Gi3 Loggtellere:                 rolleendring til aktiv: 1 rolleendring til ventemodus: 1 deaktivering av hendelser: rg ned tilstand 0, rg lukk 0 ctrl intf hendelser: opp 1, ned 0, admin_down 0 omlastingshendelser: lokal forespørsel 0, nodeforespørsel 0 RG Media Context for RG 1 -------------------------- Ctx-tilstand: Aktiv protokoll-ID: 1 medietype: Standard kontrollgrensesnitt: GigabitEthernet3 Gjeldende tidtaker for hei: 3000 Konfigurert Hei-tidtaker: 3000, Hold timer: 10000 Peer Hello-tidtaker: 3000, Peer Hold timer: 10000 statistikk:             Pkts 1509, Bytes 93558, HA seq 0, seq nummer 1509, pkt tap 0 Autentisering ikke konfigurert Autentiseringsfeil: 0 Reload node: TX 0, RX 0 Avvikling: TX 0, RX 0 Standy Peer: Til stede. Hold Timer: 10000 Pkts 61, Bytes 2074, HA Seq 0, Seq Number 69, Pkt Tap 0 VCUBE-1#
 VCUBE-2#vis overflødighetsapplikasjonsgruppe alle Feil oppgir gruppe 1-informasjon:        Kjøretidsprioritet: [100] RG feil RG-tilstand: Opp.                        Totalt antall svitsjer på grunn av feil:  0 Totalt antall endringer ned/opp på grunn av feil: 0 Gruppe-ID:1 Gruppenavn:LocalGateway-HA Administrativ tilstand: Ingen driftstilstand for nedlukningsaggregat: Opp  Min rolle: VENTEMOTPARTSROLLE: AKTIV nodetilstedeværelse: Ja motpartskomma: Ja Peer-progresjon startet: Ja RF-domene: btob-én RF-tilstand: RF-status for AKTIV node: STANDBY HOT RG Protocol RG 1 ------------------ Rolle: Aktiv forhandling: Aktivert prioritet: 100 Protokolltilstand: Aktiv(e) Ctrl Intf-tilstand: Opp aktiv motpart: adresse 10.1.1.2, prioritet 100, intf Gi3 Standby Peer: Lokale loggtellere:                 rolleendring til aktiv: 1 rolleendring til ventemodus: 1 deaktivering av hendelser: rg ned tilstand 0, rg lukk 0 ctrl intf hendelser: opp 1, ned 0, admin_down 0 omlastingshendelser: lokal forespørsel 0, nodeforespørsel 0 RG Media Context for RG 1 -------------------------- Ctx-tilstand: Aktiv protokoll-ID: 1 medietype: Standard kontrollgrensesnitt: GigabitEthernet3 Gjeldende tidtaker for hei: 3000 Konfigurert Hei-tidtaker: 3000, Hold timer: 10000 Peer Hello-tidtaker: 3000, Peer Hold timer: 10000 statistikk:             Pkts 1509, Bytes 93558, HA seq 0, seq nummer 1509, pkt tap 0 Autentisering ikke konfigurert Autentiseringsfeil: 0 Reload node: TX 0, RX 0 Avvikling: TX 0, RX 0 Standy Peer: Til stede. Hold Timer: 10000 Pkts 61, Bytes 2074, HA Seq 0, Seq Number 69, Pkt Tap 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 konfigurasjonen av lokal gateway på både plattformene, VCUBE-1 og VCUBE-2. Brukernavnet og passordet for dette oppsettet er som følger:

  • Brukernavn: Hussain1076_LGU

  • Passord: lOV12SMeS

1

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

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

Her er konfigurasjonen av lokal gateway som vil gjelde for begge plattformene basert på Control Hub-parametrene vist ovenfor, lagre og last inn på nytt. SIP Digest-legitimasjon fra Control Hub er uthevet i fet.

 konfigurere terminal crypto pki trustpoint dummyTp tilbakekalling-check crl exit sip-ua kryptosignalisering standard trustpoint dummyTp cn-san-validert servertransport tcp tls v1.2 end konfigurere terminal crypto pki trustpool import clean url http://www.cisco.com/security/pki/trs/ios_core.p7b ende konfigurere terminaltaletjeneste voip ip-adresse klarert liste ipv4 x.x.x.x y.y.y.y.y.y.y.y.y.y-tilkoblinger sip til sip media statistikk media massestatistikk ingen tilleggstjeneste sip referer ingen tilleggstjeneste sip-håndtak-erstatter faksprotokoll gjennomgang g711ulaw stun stun flytdata agent-id 1 oppstartsantall 4 flytdata delt-hemmelig 0 Passord123! sip g729 annexb-alle tidlig tilbud tvungen ende konfigurere terminaltaleklasse sip-profiler 200 regel 9 forespørsel ENHVER sip-topptekst SIP-Req-URI endre "sips:(.*)" "<sip:\1" regel 10 forespørsel ENHVER sip-topptekst For å endre "<sips:(.*)" "<sip:\1" regel 11 forespørsel ENHVER sip-topptekst Fra å endre "<sips:(.*)" "<sip:\1" regel 12 forespørsel ENHVER sip-topptekst Kontakt endre "<sips:(.*)" "<sip:\1" regel 13 svar ENHVER sip-topphussain1076_lgu>" regel 30 forespørsel om ENHVER sip-header P-Asserted-Identity endre "sips:(.*)" "sip:\1" taleklasse kodek 99 kodek preferanse 1 g711ulaw kodek preferanse 2 g711ulaw utgå taleklasse srtp-crypto 200 crypto 1 AES_cm_128_hmac_sha1_80 utgang taleklasse stun-bruk 200 stun-bruk brannmur-traversal flytdata utgang taleklasse tenant 200 registrator dns:40462196.cisco-bcld.com skjemaet SIPS utløper 240 oppdateringsforhold 50 tcp tls legitimasjonsnummer Hussain5091_lgu brukernavn Hussain1076_LGU passord 0 lOV12SMeS BroadWorks-godkjenningsbrukernavn Hussain5091_lgu passord 0 lOV12SMeS BroadWorks-godkjenningsbrukernavn Hussain5091_lgu passord 0 lOV12SMeS rike 40462196.cisco-bcld.com ingen ekstern part-ID SIP-server dns:40462196.cisco-bcld.com tilkobling-gjenbruk srtp-crypto 200 økt transport tcp tls url sips error-passthru asserted-id pai bind control kildegrensesnitt GigabitEthernet1 bind media kildegrensesnitt GigabitEthernet1 ingen pass-thru innhold egendefinert-sdp sip-profiler 200 utgående-proxy dns:la01.sipconnect-us10.cisco-bcld.com personvernpolicy passthru taleklassetenant 100 økttransport udp url sip error-passthru bind control kildegrensesnitt GigabitEthernet2 bind media source-grensesnitt GigabitEthernet2 ingen pass-thru innhold tilpasset sdp voice class tenant 300 bind control source-grensesnitt GigabitEthernet2 bind media source-grensesnitt GigabitEthernet2 ingen pass-thru innhold tilpasset sdp voice class uri 100 sip vert ipv4:198.18.133.3 taleklasse uri 200 sip mønster dtg=hussain1076.lgu oppringingsnode stemme 101 voip-beskrivelse Utgående oppringingsnode til IP PSTN-destinasjonsmønster BAD.BAD øktprotokoll sipv2 øktmål ipv4:198.18.133.3 taleklasse-kodek 99 taleklasse sip-tenant 100 dtmf-relay rtp-nte no vad oppringingsnode stemme 201 voip-beskrivelse Utgående oppringingsnode til Webex Calling-destinasjonsmønster BAD.BAD øktprotokoll sipv2 øktmål sip-server taleklasse kodek 99 taleklasse-bruk 200 ingen taleklasse sip localhost taleklasse sip-tenant 200 dtmf-relay rtp-nte srtp no vad taleklasse dpg 100 beskrivelse Innkommende WebexCalling(DP200) til IP PSTN(DP101) oppringingsnode 101 preferanse 1 taleklasse dpg 200 beskrivelse Innkommende IP PSTN(DP100) til Webex Calling(DP201) oppringingsnode 201 preferanse 1 taleklasse stemme 100 voip-desripping Innkommende oppringingsnode fra IP PST

For å vise visningskommandoen har vi lastet VCUBE-2 på nytt etterfulgt av VCUBE-1, slik at VCUBE-1 er standby CUBE og VCUBE-2 er den aktive CUBE

2

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

vis overflødighetsapplikasjonsgruppe 1

vissip-uaregistreringsstatus 

 VCUBE-1#vis overflødighetsprogram gruppe 1 Gruppe-ID:1 Gruppenavn:LocalGateway-HA Administrativ tilstand: Ingen driftstilstand for nedlukningsaggregat: Opp  Min rolle: Ventemotpartsrolle : AKTIV nodetilstedeværelse: Ja motpartskomma: Ja Peer-progresjon startet: Ja RF-domene: btob-én RF-tilstand: RF-status for STANDBY Hot Peer: ACTIVE VCUBE-1#vis sip-ua-registreringsstatus VCUBE-1#

 VCUBE-2#vis overflødighetsprogram gruppe 1 Gruppe-ID:1 Gruppenavn:LocalGateway-HA Administrativ tilstand: Ingen driftstilstand for nedlukningsaggregat: Opp  Min rolle: AKTIV noderolle: STATUS Peer Presence: Ja motpartskomma: Ja Peer-progresjon startet: Ja RF-domene: btob-én RF-tilstand: RF-status for AKTIV node: STANDBY HOT VCUBE-2#vis status for sip-ua-registrering Leier: 200 --------------------registrerings-indeks  1 --------------------- Linjenode utløper (sek) reg overlevelse P-Associ-URI ============================== ============ ========== =========== Hussain5091_LGU -1 48 ja normal VCUBE-2#

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

3

Aktiver nå følgende feilsøking på VCUBE-1

 VCUBE-1#debug ccsip ikke-anrop SIP Out-of-Dialog sporing er aktivert VCUBE-1#debug ccsip info SIP Call info sporing er aktivert VCUBE-1#debug ccsip melding

4

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

 VCUBE-2#overflødighetsprogram laster opp gruppe 1 selv

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

  • Når den AKTIVE ruteren lastes på nytt

  • Når den AKTIVE ruteren slår på

  • Når et RG-konfigurert grensesnitt til den AKTIVE ruteren avsluttes for hvilket sporing er aktivert

5

Sjekk om VCUBE-1 har registrert seg med Webex Calling access SBC. VCUBE-2 ville vært lastet på nytt nå.

 VCUBE-1#show sip-ua registerstatus leietaker: 200 --------------------registrerings-indeks  1 --------------------- Linjenode utløper (sek) reg overlevelse P-Associ-URI ============================== ========== ============ ========== ============ Hussain5091_LGU -1 56 yes normal VCUBE-1#

VCUBE-1 er nå den aktive LGW.

6

Se på den aktuelle feilsøkingsloggen på VCUBE-1 ved å sende et SIP-REGISTER til Webex Calling VIA den virtuelle IP-adressen og motta en 200 OK.

 VCUBE-1#vis logg Jan 9:37:24.769: %RG_MEDIA-3-TIMERUTLØPT: RG id 1 Hei Time Utløpt. Jan 9 18:37:24.771: %RG_PROTCOL-5-ROLECHANGE: RG-id 1-rolleendring fra Standby til Aktiv Jan 9 18:37:24.783: %VOICE_HA-2-SWITCHOVER_IND: BYTTE, fra STANDBY_HOT til AKTIV tilstand. Jan 9 18:37:24.783: //-1/xxxxxxxxxxxx/SIP/Info/info/4096/sip_ha_notify_active_role_event: Mottatt varsel om aktiv rolle 9. januar 18:37:25.758: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Sendt: REGISTRER sip: 40462196.cisco-bcld.com:5061 SIP/2.0 Via: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK0374 Fra: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 Til: <sip:Hussain5091_LGU@40462196.cisco-bcld.com> Dato: Thu, 09. jan 2020 18:37:24 GMT Anrops-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 Brukeragent: Cisco-SIPGateway/IOS-16.12.02 Maks. viderekobling: 70 Tidsstempel: 1578595044 CSeq: 2 REGISTRER kontakt: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls> Utløper: 240 Støttet: bane Innhold-Lengde: 0 

Jan 9 18:37:25.995: //-1/000000000000/SIP/Msg/ccsipDisplayMsg: Mottatt: SIP/2.0 401 Uautorisert via: SIP/2.0/TLS 198.18.1.228:5061;mottatt=173.38.218.1;branch=z9hG4bK0374;rport=4742 Fra: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 til: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1324701502-1578595045969 Dato: Thu, 09. jan 2020 18:37:24 GMT Anrops-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 Tidsstempel: 1578595044 CSeq: 2 REGISTRER WWW-Authenticate; DIGEST realm="BroadWorks",qop="auth",nonce="BroadWorksXk572qd01Ti58zliBW",algorithm=MD5 Innhold-lengde: 0 

Jan 9 18:37:26.000: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Sendt: REGISTRER SIP:40462196.cisco-bcld.com:5061 SIP/2.0 Via: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK16DC Fra: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 Til: <sip:Hussain5091_LGU@40462196.cisco-bcld.com> Dato: Thu, 09. jan 2020 18:37:25 GMT Anrops-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 Brukeragent:Cisco-SIPGateway/IOS-16.12.02 Maks-viderekobling: 70 Tidsstempel: 1578595045 CSeq: 3 REGISTRER kontakt: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls> Utløper: 240 Støttet: bane godkjenning: Sammendrag username="Hussain1076_LGU",realm="BroadWorks",uri="sips:40462196.cisco-bcld.com:5061",response="b6145274056437b9c07f7ecc08ebdb02",nonce="BroadWorksXk572qd01Ti58z1iBW",cnonce="3E0E2C4D",qop=auth,algorithm=MD5,nc=00000001 Innhold-lengde: 0 

Jan 9 18:37:26.190: //1/000000000000/SIP/Msg/ccsipDisplayMsg:  Mottatt: SIP/2.0 200 OK Via: SIP/2.0/TLS 198.18.1.228:5061;mottatt=173.38.218.1;branch=z9hG4bK16DC;rport=4742 Fra: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 til: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1897486570-1578595-46184 Ring-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 Tidsstempel: 1578595045 CSeq: 3 REGISTRER kontakt: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>;expires=120;q=0,5 tillatelseshendelser: call-info,line-seier,dialog,melding-sammendrag,som-funksjon-hendelse,x-broadworks-hoteling,x-broadworks-call-center-status,konferanse Innhold-lengde: 0