Fundamentals

Forudsætninger

Før du installerer kube HA som en lokal gateway for Webex-opkald, skal du sørge for, at du har en dybtgående forståelse af følgende begreber:

De konfigurations retningslinjer, der er angivet i denne artikel, forudsætter en dedikeret lokal gateway platform uden nogen eksisterende stemme konfiguration. Hvis en eksisterende kube implementeres i en virksomhed, der er ved at blive ændret til også at bruge den lokale gateway funktion for Cisco Webex Calling, skal du betale opmærksomheden på konfigurationen, der gælder for at sikre, at eksisterende opkalds strømme og-funktioner ikke bliver afbrudt, og at du overholder de kube HA-design krav.

Hardware-og software komponenter

KUBE HA som lokal gateway kræver IOS-XE version 16.12.2 eller nyere og understøttes på følgende platforme:

  • ISR4000-serien – 4321, 4331, 4351, 4431, 4451, 4461 (IOS-XE 17.2.1 r)
  • CSR1000-serien – vCUBE (1, 2 og 4 vCPU konfigurationer)


Visnings kommandoerne og loggene i denne artikel er baseret på en minimum softwareversion af Cisco IOS-XE 16.12.2, der er implementeret på en vCUBE (CSR1000v).

Reference materiale

Oversigt over Webex-opkald løsning

Cisco Webex Calling er et tilbud om samarbejde, der tilbyder multi-lejer cloud-baseret alternativ til on-premise PBX-telefontjeneste med to PSTNs valgmuligheder for kunder:

  • Cloud-tilsluttet PSTN udbyder
  • Lokal gateway

Den lokale gateway installation (repræsenteret nedenfor) er i fokus i denne artikel. Lokal gateway er den nye valgmulighed for PSTN for Cisco Webex Calling ved at oprette forbindelse til en kunde ejet PSTN tjeneste. Den giver også mulighed for tilslutning til en lokal IP PBX-udrulning, såsom Cisco Unified CM. Al kommunikation til og fra skyen er sikret ved hjælp af TLS transport til SIP-og SRTP for medier.

Figuren herunder viser en Webex-opkald installation uden eksisterende IP-PBX og er gældende for en enkelt eller en installation med flere websteder. Konfiguration, der er angivet i denne artikel, er baseret på denne installation.

Layer 2-Box-til-boks-redundans

CUBE HA Layer 2 Box-til-box redundans bruger redundansgruppe (RG)-infrastruktur protokollen til at danne et aktivt/standby-par af routere. Dette par deler den samme virtuelle IP-adresse (VIP) på tværs af deres respektive grænseflader og kontinuerligt Exchange-statusmeddelelser. Oplysninger om kube session er påkrævede på tværs af de routere, der gør det muligt for standby-routeren at tage alle tilmeldings ansvarsområder med det samme, hvis den aktive router forlader tjeneste, hvilket resulterer i, at signalering og medier er i høj levetid.


Kontrol Pointing er begrænset til tilsluttede opkald med medie pakker. Opkald i transit er ikke påpeget (for eksempel en prøve eller ringe tilstand).

I denne artikel vil kube HA henvise til den kube, der er i høj tilgængelighed (HA) Layer 2-box (B2B) for stateful opkaldsbevaring

Fra og med IOS-XE 16.12.2 kan kube HA installeres som lokal gateway for Cisco Webex Calling-installationer, og vi vil dække overvejelser og konfigurationer i denne artikel. Denne figur viser en typisk kube HA-opsætning som lokal gateway for en Cisco Webex Calling installation.

Redundansgruppe komponent

Redundans gruppen (RG) infrarøde komponent leverer understøttelse af Box-til-boks-kommunikationsinfrastruktur mellem de to kuber og forhandler den endelige stabile tilstand. Denne komponent giver også:

  • En HSRP-like-protokol, der forhandler den endelige redundans tilstand for hver router ved at udveksle KeepAlive og Hej meddelelser mellem de to kuber (via kontrol grænsefladen) – GigabitEthernet3 i ovenstående figur.
  • En transportmekanisme til kontrol af, at signaler og medietilstand for hvert opkald fra den aktive til standby-routeren (via data grænsefladen) – GigabitEthernet3 i figuren ovenfor.

  • Konfiguration og administration af den virtuelle IP (VIP)-grænseflade for trafik grænseflader (flere trafik grænseflader kan konfigureres med den samme RG-gruppe) – GigabitEthernet 1 og 2 betragtes som trafik grænseflader.

Denne RG-komponent skal konfigureres specifikt til at understøtte stemmens B2B-HA.

Administration af virtuel IP (VIP)-adresse til både signaler og medier

B2B HA er afhængig af VIP for at opnå redundans. VIP og tilknyttede fysiske grænseflader på begge kuber i kube HA-parret skal være placeret på det samme LAN-undernet. Konfiguration af VIP og binding af VIP-grænsefladen til en bestemt stemme applikation (SIP) er obligatorisk for understøttelse af Voice B2B HA. Eksterne enheder såsom Unified CM, Webex-opkald adgang til SBC, tjenesteudbyder eller proxy, brug VIP som destinations-IP-adresse for opkaldene ved siden af kube HA-routerne. Derfor fungerer kube HA-par som en enkelt lokal gateway fra en Webex-opkald visnings punkt.

Opkalds signaler og RTP-sessionsoplysninger om etablerede opkald er kontrolleret fra den aktive router til standby-routeren. Når den aktive router går ned, går standby-routeren over og fortsætter med at videresende den RTP-stream, der tidligere blev sendt af den første router.

Opkald i en midlertidig tilstand på tidspunktet for failover vil ikke blive bevaret efter skiftet. For eksempel er opkald, der endnu ikke er helt etableret, eller er i gang med at blive ændret med en overførsels-eller afventende funktion. Fastlagte opkald kan blive afbrudt efter skiftet.

Der findes følgende krav til brug af kube HA som lokal gateway til stateful-failover for opkald:

  • KUBE HA kan ikke have TDM eller analoge grænseflader fælles

  • Gig1 og Gig2 kaldes for trafik (SIP/RTP) grænseflader og Gig3 er redundansgruppe (RG) Control/data interface

  • Højst 2 kube HA-par kan placeres i det samme lag 2-domæne, en med gruppe-id 1 og det andet med gruppe-id 2. Hvis du konfigurerer 2 HA par med det samme gruppe-id, skal RG Control/data grænseflader tilhøre forskellige Layer 2-domæner (VLAN, separat switch)

  • Port Channel understøttes for både RG Control/data og trafik grænseflader

  • Al signalering/medie er kildet fra/til den virtuelle IP-adresse

  • Når en platform genindlæses i en kube-HA-relation, starter den altid som standby

  • Lavere adresse for alle grænsefladerne (Gig1, Gig2, Gig3) bør være på samme platform

  • Redundans grænseflade-id, Rii bør være unik for en kombination af par/grænseflader på det samme lag 2

  • Konfiguration på begge kuber skal være ens inklusive den fysiske konfiguration og skal køre på den samme type platform og IOS-XE-version

  • Tilbagekoblings grænseflader kan ikke bruges som bindende, da de altid er op

  • Flere trafik (SIP/RTP) grænseflader (Gig1, Gig2) kræver interface-sporing for at blive konfigureret

  • KUBE-HA understøttes ikke over kryds kabeltilslutning for RG-Control/data-linket (Gig3)

  • Begge platforme skal være ens og være forbundet via en fysisk switch på tværs af alle ens grænseflader for kube ha for at arbejde, dvs. GE0/0/0 af kube-1 og kube-2 skal afsluttes på den samme switch og så videre.

  • Kan ikke få WAN afsluttet på kuber direkte eller på data HA på hver side

  • Både aktiv/standby skal være i det samme datacenter

  • Det er obligatorisk at bruge separat L3-grænseflade til redundans (RG Control/data, Gig3). den grænseflade, der bruges til trafik, kan ikke bruges til HA keepalives og kontrolpunkt

  • Efter failover gennemgår den tidligere aktive kube gennem en genindlæsning efter design, bevarelse af signal og medie

Konfigurer redundans på begge kuber

Du skal konfigurere Layer 2 Box-til-boks redundans på begge kuber, der skal bruges i et HA-par for at få virtuel IPs.

1

Konfigurer sporing af brugergrænsefladen på et globalt niveau for at spore status for grænsefladen.

conf m spor 1 grænseflade GigabitEthernet1 linje-protokol spor 2 grænseflade GigabitEthernet2 linje-protokol udgang
VCUBE-1 # conf t
VCUBE-1 (config) #spor 1 grænseflade GigabitEthernet1 linje-protokol
VCUBE-1 (config-track) #spor 2 grænseflade GigabitEthernet2 linje-protokol
VCUBE-1 (config-track) #exit
VCUBE-2 # conf t
VCUBE-2 (config) #spor 1 grænseflade GigabitEthernet1 linje-protokol
VCUBE-2 (config-track) #spor 2 grænseflade GigabitEthernet2 linje-protokol
VCUBE-2 (config-track) #exit

Spor CLI bruges i RG til at spore stemmens grænseflade tilstand, så den aktive rute vil være den aktive rolle helt, når trafik grænsefladen er nede.

2

Konfigurer en RG til brug med VoIP HA under den applikationens redundans under tilstand.

redundans applikation redundansgruppe 1 navn Local gateway-HA prioritet 100 failover-tærskel 75 kontrol GigabitEthernet3 protokol 1 data GigabitEthernet3 timere forsinkelse 30 Genindlæs 60 spor 1 lukning spor 2 luknings protokol 1 timere hellotime 3 holdtime 10 Afslut Forlad Afslut
VCUBE-1 (config) #redundans
VCUBE-1 (config-Red) #applikations redundans
VCUBE-1 (config-Red-app) #gruppe 1
VCUBE-1 (config-Red-app-GRP) #Name Local gateway-ha
VCUBE-1 (config-Red-app-GRP) #priority 100 failover-tærskel 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) #timer forsinkelse 30 genindlæs 60
VCUBE-1 (config-Red-app-GRP) #spor 1 lukning
VCUBE-1 (config-Red-app-GRP) #spor 2 lukning
VCUBE-1 (config-Red-app-GRP) #Afslut
VCUBE-1 (config-Red-app) #protokol 1
VCUBE-1 (config-Red-app-prtcl) #timere hellotime 3 holdtime 10
VCUBE-1 (config-Red-app-prtcl) #Afslut
VCUBE-1 (config-Red-app) #Afslut
VCUBE-1 (config-Red) #Afslut
VCUBE-1 (config) #
VCUBE-2 (config) #redundans
VCUBE-2 (config-Red) #applikations redundans
VCUBE-2 (config-Red-app) #gruppe 1
VCUBE-2 (config-Red-app-GRP) #Name Local gateway-ha
VCUBE-2 (config-Red-app-GRP) #priority 100 failover-tærskel 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) #timer forsinkelse 30 genindlæs 60
VCUBE-2 (config-Red-app-GRP) #spor 1 lukning
VCUBE-2 (config-Red-app-GRP) #spor 2 lukning
VCUBE-2 (config-Red-app-GRP) #Afslut
VCUBE-2 (config-Red-app) #protokol 1
VCUBE-2 (config-Red-app-prtcl) #timere hellotime 3 holdtime 10
VCUBE-2 (config-Red-app-prtcl) #Afslut
VCUBE-2 (config-Red-app) #Afslut
VCUBE-2 (config-Red) #Afslut
VCUBE-2 (config) #

Her er en forklaring på de felter, der bruges i denne konfiguration:

  • redundans– går i redundans tilstand

  • applikationens redundans– skifter til programmets redundans konfigurationstilstand

  • gruppe– indtræder konfigurationstilstand for redundans-applikations gruppe

  • Name Local gateway-HA– definerer navnet på rg-gruppen

  • prioritet 100 failover tærskel 75– angiver de indledende prioritets-og failover-grænser for en rg

  • timer forsinkelse 30 Genindlæs 60– konfigurerer de to gange for forsinkelse og genindlæsning

    • Forsinkelses timer, som er det tidsrum, der skal forsinke RG-gruppens initialisering og rolle forhandling, når grænsefladen kommer op – standard 30 sekunder. Interval er 0-10000 sekunder

    • Genindlæs – dette er mængden af tid til at forsinke RG-gruppe initialisering og rolle-forhandling efter et genindlæsning – standard 60 sekunder. Interval er 0-10000 sekunder

    • Standard timere anbefales, dog kan disse timer tilpasses til at imødekomme yderligere netværks konvergens forsinkelse, som kan opstå under start/genindlæsning af routerne, for at sikre, at RG-Protokolforhandlingen finder sted, efter routing i netværket har konvergeret et stabilt punkt. For eksempel, hvis det er set efter failover, at det tager op til 20 sek. for den nye STANDBY for at se den første RG-HELLO-pakke fra den nye aktive, skal timerne justeres til ' timeres forsinkelse 60 Genindlæs 120 ' til faktor i denne forsinkelse.

  • Control GigabitEthernet3 Protocol 1– konfigurerer den brugergrænseflade, der bruges til at udveksle KeepAlive og Hej meddelelser mellem de to kuber, og angiver den protokol forekomst, der vil blive knyttet til en kontrol grænseflade og åbner redundans konfigurationstilstand

  • data GigabitEthernet3– konfigurerer den grænseflade, der bruges til kontrol af datatrafik

  • spor– rg Gruppesporing af grænseflader

  • protokol 1– angiver den protokol forekomst, der vil blive knyttet til en kontrol grænseflade og åbner redundans konfigurationstilstand for applikations protokol

  • timere hellotime 3 holdtime 10– konfigurerer de to timere for hellotime og holdtime:

    • Hellotime – interval mellem efterfølgende Heje meddelelser – standard 3 sekunder. Område er 250 millisekunder-254 sekunder

    • Holdtime – intervallet mellem modtagelsen af en Hej-meddelelse og formodningen om at sende routeren mislykkedes. Denne varighed skal være større end den Heje tid – standard 10 sekunder. Område er 750 millisekunder-255 sekunder

      Vi anbefaler, at du konfigurerer holdtime-timeren til at være mindst 3 gange værdien af hellotime-timeren.

3

Aktiver Box-til-boks redundans for kube applikationen. Konfigurer RG fra det foregående trin under Voice service VoIP. Dette gør det muligt for kube applikationen at kontrollere redundans processen.

taletjeneste VoIP redundans-gruppe 1 Afslut
VCUBE-1 (config) #Voice service VoIP
VCUBE-1 (config-Voi-serviceart) #redundans-gruppe 1
% Oprettede RG 1 associatiation med Voice B2B HA; Genindlæs routeren for at få den nye konfiguration til at træde i kraft
VCUBE-1 (config-Voi-serv) # Afslut
VCUBE-2 (config) #Voice service VoIP
VCUBE-2 (config-Voi-serviceart) #redundans-gruppe 1
% Oprettede RG 1 associatiation med Voice B2B HA; Genindlæs routeren for at få den nye konfiguration til at træde i kraft
VCUBE-2 (config-Voi-serv) # Afslut

redundans-gruppe 1— tilføjelse og fjernelse af denne kommando kræver genindlæsning for at den opdaterede konfiguration kan træde i kraft. Vi genindlæser platformene, efter alle konfiguration er blevet anvendt.

4

Konfigurer Gig1-og Gig2-grænsefladerne med deres respektive virtuelle IPs, som vist nedenfor, og Anvend redundans grænseflade-id'en (Rii)

VCUBE-1 (config) #interface GigabitEthernet1
VCUBE-1 (Config-if) # redundans Rii 1
VCUBE-1 (Config-if) # redundansgruppe 1 IP-198.18.1.228 eksklusiv
VCUBE-1 (Config-if) # Afslut
VCUBE-1 (config) #
VCUBE-1 (config) #interface GigabitEthernet2
VCUBE-1 (Config-if) # redundans Rii 2
VCUBE-1 (Config-if) # redundansgruppe 1 IP-198.18.133.228 eksklusiv
VCUBE-1 (Config-if) # Afslut
VCUBE-2 (config) #interface GigabitEthernet1
VCUBE-2 (Config-if) # redundans Rii 1
VCUBE-2 (Config-if) # redundansgruppe 1 IP-198.18.1.228 eksklusiv
VCUBE-2 (Config-if) # Afslut
VCUBE-2 (config) #
VCUBE-2 (config) #interface GigabitEthernet2
VCUBE-2 (Config-if) # redundans Rii 2
VCUBE-2 (Config-if) # redundansgruppe 1 IP-198.18.133.228 eksklusiv
VCUBE-v (Config-if) # exit

Her er en forklaring på de felter, der bruges i denne konfiguration:

  • redundans Rii– konfigurerer redundans grænsefladens id for redundans gruppen. Påkrævet for at generere en virtuel MAC (VMAC)-adresse. Den samme Rii-ID-værdi skal bruges på grænsefladen for hver router (aktiv/STANDBY), som har den samme VIP.


     

    Hvis der er mere end ét B2B-par på samme LAN, skal hvert par have unikke Rii-id'er på deres respektive grænseflader (for at forhindre kollision). "Vis redundans applikations gruppe" skal angive de korrekte lokale og peer oplysninger.

  • redundansgruppe 1– tilknytter grænsefladen med den redundansgruppe, der er oprettet i trin 2 ovenfor. Konfigurer RG-gruppen, samt den, der er tildelt til denne fysiske grænseflade.


     

    Det er obligatorisk at bruge en separat grænseflade til redundans, dvs. grænsefladen, der bruges til stemme trafik, kan ikke bruges som kontrol og datagrænse flade angivet i trin 2 ovenfor. I dette eksempel bruges Gigabit interface 3 til RG Control/data

5

Gem konfigurationen af den første kube og Genindlæs den.

Den platform, der genindlæses, er altid standby.

VCUBE-1 #WR
Opbygger konfiguration...
OK
VCUBE-1 #Genindlæs
Fortsæt med genindlæsning? bekræftede

Når VCUBE-1 starter helt, skal du gemme konfigurationen af VCUBE-2 og genindlæse den.

VCUBE-2 #WR
Opbygger konfiguration...
OK
VCUBE-2 #Genindlæs
Fortsæt med genindlæsning? bekræftede
6

Bekræft, at Box-til-boks-konfigurationen fungerer som forventet. Relevant output fremhæves med fed skrift.

Vi har genindlæst VCUBE-2 sidste og i henhold til design overvejelserne. platformen til at genindlæse den sidste vil altid være standby.

VCUBE-1 #Vis redundans applikations gruppe alle fejltilstande gruppe 1 info: Kørselsprioritet: [100] RG-fejl RG tilstand: Op. Samlet antal switchovers på grund af fejl: 0 samlet antal ændringer i alt/up-tilstand på grund af fejl: 0 gruppe-id: 1 gruppenavn: Local gateway-ha- administrationstilstand: Ingen lukning samlet driftstilstand:  Min rolle: AKTIV peer-rolle: Status for STANDBY peer: Ja peer-COMML: Ja peer-statussen startet: Ja RF-domæne: BtoB-en RF-tilstand: AKTIV peer-RF-tilstand: RG-protokol til STANDBY-RG 1-------------------rolle: Aktiv forhandling: Aktiveret prioritet: 100 protokol tilstand: Aktiv CTRL-Intf (e) tilstand: Aktiv peer: Lokal standby-peer: adresse 10.1.1.2, prioritet 100, intf Gi3 Log-tællere: rolle ændring til aktiv: 1 rolle ændring til standby: 1 Deaktiver begivenheder: rg ned-tilstand 0, rg lukket 0 CTRL intf events: op til 1, ned 0, admin_down 0 Genindlæs begivenheder: lokal anmodning 0, peer-anmodning 0 RG-medie kontekst for RG 1--------------------------ctx tilstand: Aktiv protokol-ID: 1 medietype: Standard kontrol grænseflade: GigabitEthernet3 nuværende Hej-timer: 3000 konfigureret Hej timer: 3000, hold timer: 10000 peer-Hej timer: 3000, peer hold-timer: 10000 stats statistik: Pkts 1509, byte 93558, HA sekvens 0, sekvensnummer 1509, pkt tab 0-godkendelse ikke konfigureret bekræftelses fejl: 0 Genindlæs peer: TX 0, RX 0 Opgiv: TX 0, RX 0 holder peer: Stede. Hold timer: 10000 Pkts 61, byte 2074, HA sekvens 0, sekvensnummer 69, pkt tab 0 VCUBE-1 #
VCUBE-2 #Vis redundans applikations gruppe alle fejltilstande gruppe 1 info: Kørselsprioritet: [100] RG-fejl RG tilstand: Op. Samlet antal switchovers på grund af fejl: 0 samlet antal ændringer i alt/up-tilstand på grund af fejl: 0 gruppe-id: 1 gruppenavn: Local gateway-ha- administrationstilstand: Ingen lukning samlet driftstilstand: Min rolle: STANDBY-peer-rolle: AKTIV peer-Presence: Ja peer-COMML: Ja peer-statussen startet: Ja RF-domæne: BtoB-en RF-tilstand: AKTIV peer-RF-tilstand: RG-protokol til STANDBY-RG 1-------------------rolle: Aktiv forhandling: Aktiveret prioritet: 100 protokol tilstand: Aktiv CTRL-Intf (e) tilstand: Aktiv peer: adresse 10.1.1.2, prioritet 100, intf Gi3 standby peer: Lokale logge-tællere: rolle ændring til aktiv: 1 rolle ændring til standby: 1 Deaktiver begivenheder: rg ned-tilstand 0, rg lukket 0 CTRL intf events: op til 1, ned 0, admin_down 0 Genindlæs begivenheder: lokal anmodning 0, peer-anmodning 0 RG-medie kontekst for RG 1--------------------------ctx tilstand: Aktiv protokol-ID: 1 medietype: Standard kontrol grænseflade: GigabitEthernet3 nuværende Hej-timer: 3000 konfigureret Hej timer: 3000, hold timer: 10000 peer-Hej timer: 3000, peer hold-timer: 10000 stats statistik: Pkts 1509, byte 93558, HA sekvens 0, sekvensnummer 1509, pkt tab 0-godkendelse ikke konfigureret bekræftelses fejl: 0 Genindlæs peer: TX 0, RX 0 Opgiv: TX 0, RX 0 holder peer: Stede. Hold timer: 10000 Pkts 61, byte 2074, HA sekvens 0, sekvensnummer 69, pkt tab 0 VCUBE-2 #

Konfigurer en lokal gateway på begge kuber

I vores eksempel konfiguration bruger vi følgende oplysninger fra Webex Control Hub til at opbygge den lokale gateway konfiguration på både platformene, VCUBE-1 og VCUBE-2. Brugernavn og adgangskode for denne opsætning er som følger:

  • Brugernavn: Hussain1076_LGU

  • Adgangskode: lOV12MEaZx

1

Sørg for, at en masternøgle er forudkonfigureret for adgangskoden med de kommandoer, der er vist nedenfor, før den kan bruges i legitimationsoplysningerne eller de delte hemmeligheder. Type 6-adgangskoder er krypteret med AES-kryptering og brugerdefineret masternøgle.

Local gateway # conf t Local gateway (config) #Key config-Key Password-Krypter Password123 Local gateway (config) #adgangskodekryptering AES

Her er den lokale gateway konfiguration, der vil gælde for begge platforme baseret på de Control hub-parametre, der er vist ovenfor, Gem og Genindlæs. SIP Digest-legitimationsoplysninger fra Control jub er fremhævet med fed 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 85.119.56.128 255.255.255.192 ipv4 85.119.57.128 255.255.255.192 ipv4 185.115.196.0 255.255.255.128 ipv4 185.115.197.0 255.255.255.128 ipv4 199.59.64.0 255.255.255.128 ipv4 199.59.65.0 255.255.255.128 ipv4 199.59.66.0 255.255.255.128 ipv4 199.59.67.0 255.255.255.128 ipv4 199.59.70.0 255.255.255.128 ipv4 199.59.71.0 255.255.255.128 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 "<sip:(.*)" "<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 codec preference 3 g729r8 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:1a01.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 at vise den viste kommandos output har vi genindlæst VCUBE-2 efterfulgt af VCUBE-1, hvilket gør VCUBE-1 standby-kuben og VCUBE-2 den aktive kube

2

Kun én platform vil på et givet tidspunkt opretholde en aktiv registrering som den lokale gateway med Webex-opkald Access SBC. Tag et kig på output af følgende show-kommandoer.

Vis redundans applikations gruppe 1

Vis SIP-UA-Tilmeldingsstatus

VCUBE-1 #Vis redundans applikations gruppe 1 gruppe-id: 1 gruppenavn: Local gateway-ha-administratortilstand: Ingen lukning samlet driftstilstand: op min rolle: Standby- peer-rolle: AKTIV peer-Presence: Ja peer-COMML: Ja peer-statussen startet: Ja RF-domæne: BtoB-en RF-tilstand: STANDBY HOT peer-RF tilstand: AKTIV VCUBE-1 #Vis SIP-UA-Tilmeldingsstatus VCUBE-1 #
VCUBE-2 #Vis redundans applikations gruppe 1 gruppe-id: 1 gruppenavn: Local gateway-ha-administratortilstand: Ingen lukning samlet driftstilstand: op min rolle: AKTIV peer-rolle: STATUS for peer-Presence: Ja peer-COMML: Ja peer-statussen startet: Ja RF-domæne: BtoB-en RF-tilstand: AKTIV peer-RF-tilstand: STANDBY HOT VCUBE-2 #Vis SIP-UA register status- lejer: 200--------------------registrator-indeks 1---------------------linje peer udløber (sek) reg overlevelse P-associ-URI = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = 1 48 Hussain5091_LGU #

Fra ovenstående resultat kan du se, at VCUBE-2 er den aktive LGW, der vedligeholder tilmeldingen med WEBEX-opkald Access SBC, hvorimod resultatet af "Vis SIP-UA-register status" er tom i VCUBE-1

3

Aktiver nu følgende fejl i VCUBE-1

VCUBE-1 #fejlfinding ccsip ikke-ring til SIP uden for dialog boks sporing er aktiveret VCUBE-1 #fejlfinding ccsip info SIP-opkald info sporing er aktiveret VCUBE-1 #fejlfinding ccsip meddelelse
4

Simuler failover ved at udstede følgende kommando på den aktive LGW, VCUBE-2 i dette tilfælde.

VCUBE-2 #redundans program Genindlæs gruppe 1 selv

Skiftet fra aktiv til STANDBY-LGW sker i det følgende scenario foruden CLI angivet ovenfor

  • Når den aktive router genindlæses
  • Når den aktive router strøm cyklus
  • Når en RG-konfigureret grænseflade for den aktive router er lukket, for hvilken sporing er aktiveret
5

Marker for at se, om VCUBE-1 er tilmeldt med Webex-opkald Access SBC. VCUBE-2 ville blive genindlæst med nu.

VCUBE-1 #Vis SIP-UA register status-lejer: 200--------------------registrator-indeks 1---------------------linje peer udløber (sek) reg overlevelse P-associ-URI = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = 1 56 Hussain5091_LGU  #

VCUBE-1 er nu den aktive LGW.

6

Se på den relevante fejlfindingslogfil på VCUBE-1, der sender et SIP-REGISTER til Webex-opkald VIA den virtuelle IP og modtager en 200 OK.

VCUBE-1 # Vis log Jan 9 18:37:24.769: % RG_MEDIA -3-TIMEREXPIRED: RG-id 1 Hej-tid udløbet. Januar 18:37:24.771: % RG_PROTCOL -5-ROLECHANGE: RG id 1 rolle ændring fra standby til aktiv 9 18:37:24.783: % VOICE_HA-2-SWITCHOVER_IND: SKIFTET fra STANDBY_HOT til aktiv tilstand. Januar 18:37:24.783: -1/xxxxxxxxxxxx/SIP/info/info/4096/sip_ha_notify_active_role_event: Modtaget Giv besked om aktiv rolle begivenhed Jan 9 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: Tor, 09 Jan 2020 18:37:24 GMT Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97-bruger agent: Cisco-SIPGateway/IOS-16.12.02 Max-Forward: 70 tidsstempel: 1578595044 CSeq: 2 Tilmeld kontakt: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls> Udløber: 240 understøttet: Path Content-Length: 0
Januar 18:37:25.995: -1/000000000000/SIP/msg/ccsipDisplayMsg: Modtaget: SIP/2.0 401 uautoriseret via: SIP/2.0/TLS 198.18.1.228:5061; modtaget = 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: Tor, 09 Jan 2020 18:37:24 GMT Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 Timestamp: 1578595044 CSeq: 2 Tilmeld dig WWW-Godkend; DIGEST realm = "BroadWorks", qop = "auth", nonce = "BroadWorksXk572qd01Ti58zliBW", algoritme = MD5 indhold-længde: 0
Januar 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: Tor, 09 Jan 2020 18:37:25 GMT Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97-bruger agent: Cisco-SIPGateway/IOS-16.12.02 Max-forwards: 70 tidsstempel: 1578595045 CSeq: 3 Tilmeld kontakt: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls> Udløber: 240 understøttet: Tilladelse til Path: Digest username = "Hussain1076_LGU", realm = "BroadWorks", URI = "SIPS:40462196. Cisco-BCLD. com: 5061", Response = "b6145274056437b9c07f7ecc08ebdb02", nonce = "BroadWorksXk572qd01Ti58z1iBW", cnonce = "3E0E2C4D", qop = auth, algoritme = 0
Januar 18:37:26.190: 1/000000000000/SIP/msg/ccsipDisplayMsg: Modtaget: SIP/2.0 200 OK via: SIP/2.0/TLS 198.18.1.228: 5061; modtaget = 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>; Tags = SD1u8bd99-1897486570-1578595-46184 Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 Timestamp: 1578595045 CSeq: 3 Tilmeld kontakt: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>; udløber = 120; q = 0,5 Allow-events: opkald-info, linje beslag, dialog, meddelelse-Oversigt, som funktion-begivenhed, x-broadworks-Hotel, x-broadworks-opkald-Center-status, konference indhold-længde: 0