Grunderna

Förutsättningar

Innan du distribuerar CUBE HA som en lokal gateway för Webex Calling ska du se till att du verkligen förstår följande koncept:

Konfigurationsriktlinjerna i den här artikeln utgår från en dedikerad lokal gatewayplattform utan någon befintlig röstkonfiguration. Om en befintlig CUBE-företagsdistribution ändras för att även använda den lokala gatewayfunktionen för Cisco Webex Calling ska du vara uppmärksam på konfigurationen som tillämpas för att säkerställa att befintliga samtalsflöden och funktioner inte avbryts och se till att du följer CUBE HA-designkraven.

Maskinvaru- och programvarukomponenter

CUBE HA som lokal gateway kräver IOS-XE version 16.12.2 eller senare och en plattform där både CUBE HA- och lokala gatewayfunktioner stöds.

Kommandon och loggar i den här artikeln baseras på minst programvaruversion Cisco IOS-XE 16.12.2 implementerad på en vCUBE (CSR1000v).

Referensmaterial

Här är några detaljerade konfigurationsguider för CUBE HA för olika plattformar:

Översikt över Webex Calling-lösning

Cisco Webex Calling är ett samarbetserbjudande som tillhandahåller ett molnbaserat alternativ med flera klienter till en lokal PBX-telefontjänst med flera PSTN-alternativ för kunder.

Distribution av lokal gateway (som representeras nedan) är i fokus för den här artikeln. Trunk för lokal gateway (platsbaserad PSTN) i Webex Calling gör det möjligt att ansluta till en PSTN-tjänst som ägs av kunden. Den ger också anslutning till en lokal IP PBX-distribution, till exempel Cisco Unified CM. All kommunikation till och från molnet är säker med TLS-transport för SIP och SRTP för media.

Figuren nedan visar en Webex Calling-distribution utan någon befintlig IP PBX och kan tillämpas på en distribution på enskild eller flera platser. Konfigurationen som beskrivs i den här artikeln baseras på den här distributionen.

2-lagers enhet-till-enhetsredundans

CUBE HA 2-lagers enhet-till-enhetsredundans använder infrastrukturprotokollet Redundansgrupp (RG) för att skapa ett par routrar som är aktiva/i vänteläge. Detta par delar samma virtuella IP-adress (VIP) över sina respektive gränssnitt och utbyter kontinuerligt statusmeddelanden. CUBE-sessionsinformation kontrolleras med ett par routrar, vilket gör att routern i vänteläge omedelbart kan ta över allt ansvar för CUBE-samtalsbearbetning om den aktiva routern går ur drift, vilket resulterar i ett tillståndskänsligt bevarande av signalering och media.

Kontrollen är begränsad till anslutna samtal med mediepaket. Samtal under överföring kontrolleras inte (till exempel i försöks- eller ringande tillstånd)

I den här artikeln hänvisar CUBE HA till CUBE High Availability (HA) 2-lagers enhet-till-enhetsredundans för tillståndskänsligt bevarande av samtal

Från och med IOS-XE 16.12.2 kan CUBE HA distribueras som en lokal gateway för Cisco Webex Calling-trunkdistributioner (platsbaserad PSTN) och vi kommer att diskutera designöverväganden och konfigurationer i den här artikeln. Denna figur visar en typisk CUBE HA-konfiguration som lokal gateway för en Cisco Webex Calling-trunkdistribution.

Infrakomponent för redundansgrupp

Infrakomponenten för redundansgrupp (RG) tillhandahåller infrastrukturstöd för enhet-till-enhetskommunikation mellan de två CUBE och förhandlar fram det slutliga stabila redundanstillståndet. Komponenten tillhandahåller även:

  • Ett HSRP-liknande protokoll som förhandlar fram det slutliga redundanstillståndet för varje router genom att utbyta keepalive- och hello-meddelanden mellan de två CUBE (via kontrollgränssnittet) – GigabitEthernet3 i figuren ovan.

  • En transportmekanism för kontroll av signalerings- och medietillstånd för varje samtal från den aktiva routern till routern i vänteläge (via datagränssnittet) – GigabitEthernet3 i figuren ovan.

  • Konfiguration och hantering av det virtuella IP-gränssnittet (VIP) för trafikgränssnitten (flera trafikgränssnitt kan konfigureras med samma RG-grupp) – GigabitEthernet 1 och 2 anses vara trafikgränssnitt.

Den här RG-komponenten måste konfigureras specifikt för att stödja röst B2B HA.

Hantering av virtuell IP-adress (VIP) för både signalering och media

B2B HA är beroende av VIP för att uppnå redundans. VIP och associerade fysiska gränssnitt för båda CUBE i CUBE HA-paret måste finnas på samma LAN-undernät. Konfiguration av VIP och bindningen av VIP-gränssnittet till ett visst röstprogram (SIP) är obligatorisk för stöd för röst B2B HA. Externa enheter, t.ex. Unified CM, SBC för Webex Calling-åtkomst, tjänsteleverantör eller proxy, använder VIP som destinations-IP-adress för samtal som passerar genom CUBE HA-routrar. Avseende Webex Calling agerar därmed CUBE HA-paren som en enda lokal gateway.

Information om samtalssignalering och RTP-session för etablerade samtal kontrolleras från den aktiva routern till routern i vänteläge. När den aktiva routern slutar fungera tar routern i vänteläge över och fortsätter vidarebefordra RTP-strömmen som tidigare dirigerades av den första routern.

Samtal som är i överföringstillstånd vid felöverlämningen kommer inte att bevaras efter växlingen. Till exempel samtal som inte har etablerats helt än eller som håller på att ändras med en överförings- eller parkeringsfunktion. Etablerade samtal kan kopplas från efter växlingen.

Följande krav gäller för användning av CUBE HA som lokal gateway för tillståndskänsliga felöverlämningar av samtal:

  • CUBE HA kan inte ha TDM eller analoga gränssnitt på samma plats

  • Gig1 och Gig2 kallas för trafikgränssnitt (SIP/RTP) och Gig3 är kontroll-/datagränssnitt för redundansgrupp (RG)

  • Högst 2 CUBE HA-par kan placeras i samma 2-lagersdomän, ett med grupp-ID 1 och det andra med grupp-ID 2. Om 2 HA-par konfigureras med samma grupp-ID måste kontroll-/datagränssnitt för RG tillhöra olika 2-lagersdomäner (vlan, separat växling)

  • Portkanalen har stöd för både kontroll-/datagränssnitt för RG och trafikgränssnitt

  • All signalering/media kommer från/till den virtuella IP-adressen

  • När en plattform laddas om i en CUBE-HA-relation startar den alltid om i Vänteläge

  • Lägre adress för alla gränssnitt (Gig1, Gig2, Gig3) ska vara på samma plattform

  • Identifieraren för redundansgränssnittet ska vara unik för en par-/gränssnittskombination på samma 2-lager

  • Konfigurationen för båda CUBE måste vara identisk, inklusive fysisk konfiguration, och måste köras på samma typ av plattform och IOS-XE-version

  • Loopback-gränssnitt kan inte användas som bindning eftersom de alltid är uppe

  • Vid flera trafikgränssnitt (SIP/RTP) (Gig1, Gig2) måste gränssnittsspårning konfigureras

  • CUBE-HA stöds inte via anslutning med korskopplad nätverkskabel för RG-kontrollänken/datalänken (Gig3)

  • Båda plattformarna måste vara identiska och anslutas via en fysisk växel över alla på liknande gränssnitt för att CUBE HA ska fungera, dvs. GE0/0/0 av CUBE-1 och CUBE-2 måste avslutas i samma växel osv.

  • WAN får inte avslutas direkt på CUBE-tillämpningarna och Data HA får inte finnas på någon sida

  • Både Aktiv och Standby måste vara i samma datacenter

  • Det är obligatoriskt att använda separat L3-gränssnitt för redundans (RG Control/-data, Gig3), dvs. gränssnitt som används för trafik får inte användas för HA-keepalives och kontrollpunkter

  • Vid felöverlämning uppdateras som standard den tidigare aktiva CUBE-applikationen, vilket innebär att signalering och media bevaras

Konfigurera redundans på båda CUBE

Du måste konfigurera 2-lagers enhet-till-enhetsredundans på båda CUBE-tillämpningarna som ska användas i ett HA-par för att få fram virtuella IP-adresser.

1

Konfigurera gränssnittsspårning på global nivå för att spåra gränssnittets status.

conf t 
 track 1-gränssnitt GigabitEthernet1 line-protocol track 2 gränssnitt 
 GigabitEthernet2 line protocol 
 exit 

VCUBE-1#conf t

VCUBE-1(config)#spåra 1-gränssnitt för GigabitEthernet1-linjeprotokoll

VCUBE-1(config-track)#spår 2-gränssnitt för GigabitEthernet2 linjeprotokoll

VCUBE-1(config-track)#avsluta

VCUBE-2#conf t

VCUBE-2(config)#spåra 1-gränssnitt för GigabitEthernet1-linjeprotokoll

VCUBE-2(config-track)#spår 2-gränssnitt för GigabitEthernet2-linjeprotokoll

VCUBE-2(config-track)#avsluta

Spåra CLI används i RG för att spåra gränssnittstillståndet för rösttrafik, så att den aktiva dirigeringens roll tystas när trafikgränssnittet ligger nere.

2

Konfigurera RG för användning med VoIP HA under underläget för programredundans.

redundans program redundansgrupp 1 namn 
 
 
    LocalGateway-HA 
    prioritet 100 redundanströskel 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 

VCUBE-1(config)#redundans

VCUBE-1(config-red)#programredundans

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

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

VCUBE-1(config-red-app-grp)#prioritet 100 felöverlämningströskel 75

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

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

VCUBE-1(config-red-app-grp)#timers fördröjning 30 läs in igen 60

VCUBE-1(config-red-app-grp)#spåra 1 avstängning

VCUBE-1(config-red-app-grp)#spår 2 avstängning

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

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

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

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

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

VCUBE-1(config-red)#avsluta

VCUBE-1 (konfiguration) #

VCUBE-2(config)#redundans

VCUBE-2(config-red)#programredundans

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

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

VCUBE-2(config-red-app-grp)#prioritet 100 felöverlämningströskel 75

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

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

VCUBE-2(config-red-app-grp)#timers fördröjning 30 läs in igen 60

VCUBE-2(config-red-app-grp)#spår 1 avstängning

VCUBE-2(config-red-app-grp)#stäng av spår 2

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

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

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

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

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

VCUBE-2(config-red)#avsluta

VCUBE-2 (konfiguration) #

Här förklaras de fält som används i den här konfigurationen:

  • redundans – Går in i redundansläge

  • Programredundans – Anger konfigurationsläge för programredundans

  • grupp – Anger gruppkonfigurationsläge för redundansprogram

  • namn LocalGateway-HA – definierar namnet på RG-gruppen

  • prioritet 100 felöverlämningströskel 75 – anger tröskelvärdena för initial prioritet och felöverlämning för en RG

  • timers fördröjning 30 ny inläsning 60– konfigurerar de två gångerna för fördröjning och ny inläsning

    • Fördröjningstimer gäller tiden det tar att fördröja RG-gruppens initiering och rollförhandling efter att gränssnittet visas – 30 sekunder som standard. Intervallet är 0–10 000 sekunder

    • Läs in igen – tiden det tar att fördröja RG-gruppinitieringen och rollförhandlingen efter en ny inläsning – 60 sekunder som standard. Intervallet är 0–10 000 sekunder

    • Standardtimer rekommenderas, även om dessa kan justeras för att tillgodose alla ytterligare konvergensfördröjningar som kan uppstå under uppstart/ny inläsning av routrarna, för att garantera att RG-protokollförhandlingen äger rum efter att dirigeringen i nätverket har konvergerats till en stabil punkt. Om det efter felöverlämning t.ex. upptäcks att det tar upp till 20 sekunder för den nya STANDBY att se det första RG HELLO-paketet från den nya ACTIVE ska denna fördröjning faktoreras in och timers justeras till ”timers delay 60 reload 120 (timers fördröjning 60 ny inläsning 120)”.

  • kontrollera GigabitEthernet3-protokoll 1 – Konfigurerar gränssnittet som används för att utbyta keepalive- och hälsningsmeddelanden mellan de två CUBE:erna och anger protokollinstansen som ska kopplas till ett kontrollgränssnitt och går in i protokollkonfigurationsläge för redundansprogram.

  • data GigabitEthernet3 – Konfigurerar gränssnittet som används för att kontrollera datatrafik

  • spåra– RG-gruppspårning av gränssnitt

  • protokoll 1 – Anger protokollinstans som ska kopplas till ett kontrollgränssnitt och går in i protokollkonfigurationsläge för redundansprogram

  • timers heltid 3 holdtid 10 – Konfigurerar de två timrarna för heltid och holdtid:

    • Hälsningstid – intervall mellan flera hälsningsmeddelanden i följd – standard 3 sekunder. Intervallet är 250 millisekunder – 254 sekunder

    • Parkeringstid – intervallet mellan mottagandet av ett hälsningsmeddelande och antagandet att ett fel har uppstått på sändningsroutern. Den här varaktigheten måste vara längre än hälsningstiden – standard 10 sekunder. Intervallet är 750 millisekunder – 255 sekunder

      Vi rekommenderar att du konfigurerar timern för parkeringstid till minst tre gånger värdet för timern för hälsningstid.

3

Aktivera enhet-till-enhetsredundans för CUBE-programmet. Konfigurera RG från föregående steg under rösttjänstensVoIP. Detta möjliggör för CUBE-programmet att styra redundansprocessen.

voip-redundans-grupp 1-utträde för 
 rösttjänst

VCUBE-1(config)#rösttjänstens VoIP

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

 % Skapade RG 1-koppling med Voice B2B HA; ladda om routern för att den nya konfigurationen ska verkställas 

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

VCUBE-2(config)#rösttjänstens VoIP

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

 % Skapade RG 1-koppling med Voice B2B HA; ladda om routern för att den nya konfigurationen ska verkställas 

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

redundansgrupp 1 – För att lägga till och ta bort det här kommandot krävs en ny inläsning för att den uppdaterade konfigurationen ska träda i kraft. Plattformarna läses in igen när hela konfigurationen har tillämpats.

4

Konfigurera Gig1 och Gig2-gränssnitten tillsammans med deras respektive virtuella IP-adresser enligt nedan och tillämpa redundansgränssnittsidentifieraren (rii)

VCUBE-1(config)#GigabitEthernet1-gränssnitt

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

VCUBE-1(config-if)# redundansgrupp 1 ip 198.18.1.228 exklusiv

VCUBE-1(config-if)# avsluta

VCUBE-1 (konfiguration) #

VCUBE-1(config)#GigabitEthernet2-gränssnitt

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

VCUBE-1(config-if)# redundansgrupp 1 ip 198.18.133.228 exklusiv

VCUBE-1(config-if)# avsluta

VCUBE-2(config)#GigabitEthernet1-gränssnitt

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

VCUBE-2(config-if)# redundansgrupp 1 ip 198.18.1.228 exklusiv

VCUBE-2(config-if)# avsluta

VCUBE-2 (konfiguration) #

VCUBE-2(config)#GigabitEthernet2-gränssnitt

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

VCUBE-2(config-if)# redundansgrupp 1 ip 198.18.133.228 exklusiv

VCUBE-v(config-if)# avsluta

Här förklaras de fält som används i den här konfigurationen:

  • redundansrii – Konfigurerar redundansgränssnittsidentifieraren för redundansgruppen. Krävs för att skapa en virtuell MAC-adress (VMAC). Samma ID-värde för rii måste användas för varje routers gränssnitt (AKTIV/STANDBY) som har samma VIP.

    Om det finns fler än ett B2B-par på samma LAN MÅSTE varje par ha unika rii-ID:n på sina respektive gränssnitt (för att förhindra kollision). ”visa alla redundansprogram-grupper” ska ange korrekt lokal information och peer-information.

  • redundansgrupp 1 – Associerar gränssnittet med redundansgruppen som skapades i steg 2 ovan. Konfigurera RG-gruppen samt den VIP som tilldelats det här fysiska gränssnittet.

    Det är obligatoriskt att använda ett separat gränssnitt för redundans, dvs. gränssnittet som används för rösttrafik inte kan användas som kontroll- och datagränssnitt enligt steg 2 ovan. I detta exempel används Gigabit-gränssnitt 3 för RG-kontroll/-data

5

Spara konfigurationen av den första CUBE-tillämpningen och läs in den på nytt.

Standby-plattformen är alltid sist att läsas in på nytt.

VCUBE-1#wr

 Byggnadskonfiguration... 

 [OK] 

VCUBE-1#läs in igen

 Vill du fortsätta med att läsa in igen? [bekräfta]

När VCUBE-1 startar upp helt, spara konfigurationen av VCUBE-2 och ladda om den.

VCUBE-2#wr

 Byggnadskonfiguration... 

 [OK] 

VCUBE-2#läs in igen

 Vill du fortsätta med att läsa in igen? [bekräfta]

6

Verifiera att enhet-till-enhetskonfigurationen fungerar som väntat. Relevant utdata markeras i fetstil.

VCUBE-2 lästes in på nytt sist och enligt designöverväganden är standbyplattformen alltid den sista att läsas in på nytt. 

 VCUBE-1#visa redundansprogramgrupp alla feltillstånd för grupp 1-information:        Runtime-prioritet: [100] RG-fel RG tillståndet: Upp.                        Totalt antal växlingar pga. fel:  0 Totalt antal status ändringar på ner/upp på grund av fel: 0 grupp-ID: 1 grupp namn: LocalGateway-ha Administratörs tillstånd: Ingen avstängning aggregerad användnings status:  Min roll: AKTIV peer-roll: VÄNTe läge för peer: Ja peer-komm: Ja-peer-förloppet startat: Ja RF-domän: BtoB-ett RF-tillstånd: RF-status för aktiv peer: RG-RG 1------------------roll: Aktiv förhandling: Aktive rad prioritet: 100 protokoll status: Aktiv status för CTRL-Intf (s): Aktiv peer: Lokal vänte läge: adress 10.1.1.2, prioritet 100, intf Gi3- logg räknare:                 roll ändras till aktiv: 1 roll har ändrats till vänte läge: 1 inaktivera händelser: RG Down State 0, RG avsluta 0 CTRL intf events: upp 1, ned 0, admin_down 0 läs in händelser igen: lokal förfrågan 0, peer Request 0 RG Media Context för RG 1--------------------------CTX-tillstånd: Active Protocol-ID: 1 medietyp: Gränssnitt för standard kontroll: GigabitEthernet3 aktuella hälsnings intervall: 3000 konfigurerade hälsnings-timer: 3000, Håll timer: 10000 peer-hälsning, timer: 3000, Peer Hold timer: 10000 statistik:             Pkts 1509, byte 93558, HA 1, 1, 1, 1 1509, 1, 1, 1, 1: a 1 = 1 = 1 autentisering misslyckades autentisering 0 Läs in peer igen: TX 0, RX 0 omsignering: TX 0, RX 0-bevarad peer: Närvarande. Håll tidsräkningen: 10000 Pkts 61, byte 2074, HA Seq 0, Seq Nummer 69, Pkt Förlust 0 VCUBE-1#
 VCUBE-2#visa redundansprogramgrupp alla feltillstånd Grupp 1-info:        Runtime-prioritet: [100] RG-fel RG tillståndet: Upp.                        Totalt antal växlingar pga. fel:  0 Totalt antal status ändringar på ner/upp på grund av fel: 0 grupp-ID: 1 grupp namn: LocalGateway-ha Administratörs tillstånd: Ingen avstängning aggregerad användnings status: Min roll: Försätta peer-rollen: AKTIV peer-närvaro: Ja peer-komm: Ja-peer-förloppet startat: Ja RF-domän: BtoB-ett RF-tillstånd: RF-status för aktiv peer: RG-RG 1------------------roll: Aktiv förhandling: Aktive rad prioritet: 100 protokoll status: Aktiv status för CTRL-Intf (s): Aktiv peer: adress 10.1.1.2, prioritet 100, intf-Gi3 vänte-peer: Lokala loggnings räknare:                 roll ändras till aktiv: 1 roll har ändrats till vänte läge: 1 inaktivera händelser: RG Down State 0, RG avsluta 0 CTRL intf events: upp 1, ned 0, admin_down 0 läs in händelser igen: lokal förfrågan 0, peer Request 0 RG Media Context för RG 1--------------------------CTX-tillstånd: Active Protocol-ID: 1 medietyp: Gränssnitt för standard kontroll: GigabitEthernet3 aktuella hälsnings intervall: 3000 konfigurerade hälsnings-timer: 3000, Håll timer: 10000 peer-hälsning, timer: 3000, Peer Hold timer: 10000 statistik:             Pkts 1509, byte 93558, HA 1, 1, 1, 1 1509, 1, 1, 1, 1: a 1 = 1 = 1 autentisering misslyckades autentisering 0 Läs in peer igen: TX 0, RX 0 omsignering: TX 0, RX 0-bevarad peer: Närvarande. Håll tidsräkningen: 10000 
 Pkts 61, Bytes 2074, HA Seq 0, Seq Number 69, Pkt Loss 0 
 
 VCUBE-2 #

Konfigurera en lokal gateway på båda CUBE

I vår exempelkonfiguration använder vi följande segmentinformation från Control Hub för att bygga den lokala gatewaykonfigurationen på båda plattformarna, VCUBE-1 och VCUBE-2. Användarnamnet och lösenordet för den här inställningen är följande:

  • Användarnamn: Hussain1076LGU_

  • Lösenord: lOV12MEaZx

1

En konfigurationsnyckel måste skapas för lösenordet med kommandona som visas nedan innan den kan användas i autentiseringsuppgifterna eller delade hemligheter. Typ 6-lösenord krypteras med AES-chiffer och denna användardefinierade konfigurationsnyckel. 

 LocalGateway#conf t LocalGateway(config)#key config-key password-encrypt Password123 LocalGateway(config)#lösenordskryptering aes

Här är den lokala gateway-konfigurationen som kommer att gälla för båda plattformarna baserat på de Control Hub-parametrar som visas ovan, Spara och ladda om. Autentiseringsuppgifter för SIP Digest från Control Hub markeras i fetstil.

 konfigurera terminal crypto pki trustpoint dummyTp återkallningskontroll crl utgång sip-ua kryptosignalering standard trustpoint dummyTp cn-san-validate server transport tcp tls v1.2 avsluta konfigurera terminal crypto pki trustpool import ren url http://www.cisco.com/security/pki/trs/ios_core.p7b avsluta konfigurera terminalrösttjänst VoIP-adress betrodd lista ipv4 x.x.x.x.x y.y.y.y avsluta tillåt-anslutningar sip till sip-mediestatistik media bulk-statistik ingen tilläggstjänst sip handersätter faxprotokoll-pass-through g711ulaw stun stun flowdata agent-ID 1 boot-count 4 stun flowdata shared-secret 0 Lösenord123! sip g729 annexb-all tidigt-erbjudande tvingad avsluta konfigurera terminalröstklass sip-profiler 200 regel 9 begäran NÅGON sip-rubrik SIP-Req-URI ändra "sips:(.*)" "<sip:\1" regel 10 begäran NÅGON sip-rubrik För att ändra "<sips:(.*)" "<sip:\1" regel 11 begäran NÅGON sip-rubrik Från ändra "<sips:(.*)" "<sip:\1" regel 12 svar NÅGON sip-rubrik För att ändra "<sips:(.*)" "<sip:\1" regel 14 svar NÅGON sip-rubrik Från att ändra "<sips:(.*)" "<sip:\1" regel 15 svarhussain1076_lgu>" regel 30 begär NÅGON SIP-RUBRIK P-Asserted-Identity ändra "sips:(.*)" "sip:\1" röstklasscodec 99 kodekinställning 1 g711ulaw kodekinställning 2 g711ulaw avsluta röstklass srtp-crypto 200 crypto 1 AES_cm_128_hmac_sha1_80 avsluta röstklassens stun-användning 200 stun-användning brandvägg-traversal flowdata avsluta röstklassens klient 200 registrator dns:40462196.cisco-bcld.com schemas sips upphör 240 uppdateringsförhållande 50 tcp tls autentiseringsnummer Hussain5091_Lgu (kommun) användarnamn Hussain1076_LGU-lösenord 0 lOV12MEaZx användarnamn för BroadWorks-autentisering Hussain5091_Lgu (kommun) lösenord 0 lOV12MEaZx användarnamn för BroadWorks-autentisering i sfären Hussain5091_Lgu (kommun) lösenord 0 lOV12MEaZx sfär 40462196.cisco-bcld.com ingen SIP-server för fjärr-part-ID dns:40462196.cisco-bcld.com anslutning-återanvänd srtp-crypto 200 sessionstransport tcp tls url sips fel-passthru asserted-id pai bind control source-gränssnitt GigabitEthernet1 bind media source-gränssnitt GigabitEthernet1 inget pass-thru innehåll anpassade-sdp sip-profiler 200 utgående proxy dns:la01.sipconnect-us10.cisco-bcld.com sekretesspolicyn passthru röstklassad klient 100 sessionstransport udp url sip fel-passthru bind kontroll källa-gränssnitt GigabitEthernet2 bind media källa-gränssnitt GigabitEthernet2 inget pass-thru innehåll anpassat-sdp röstklassad klient 300 bind kontroll källa-gränssnitt GigabitEthernet2 bind media källa-gränssnitt GigabitEthernet2 inget pass-thru innehåll anpassat-sdp röstklass uri 100 sip värd ipv4:198.18.133.3 röstklass uri 200 sip mönster dtg=hussain1076.lgu samtalskollega 101 Voip-beskrivning Utgående samtalskollega till IP PSTN-destinationsmönster BAD.BAD sessionsprotokoll sipv2-sessionsmål ipv4:198.18.133.3 röstklassens kodek 99 röstklassens sip-klient 100 dtmf-reläer rtp-nte ingen vad samtalskodek till Webex Calling-destinationsmönster BAD.BAD sessionsprotokoll sipv2-sessionssvar till Webex Calling-destinationsmönster 200 dtmf-reläer rtp-nte srtp ingen vad röstklass dpg 100 beskrivning Inkommande WebexCalling(DP200) till IP PSTN(DP101) uppringnings-peer 101 inställning 1 röstklass dpg 200 beskrivning Inkommande IP PSTN(DP100) till Webex Calling(DP201) uppringnings-peer 201 inställning 1 uppringnings-peer röst 100 voip-avription Inkommande uppringnings-peer från IP PSTN sessionsprotokoll sipv2 destination dpg 200 inkommande uri via 100 röstklasscodec 99 röstklassens sip-klient 200 voip-beskrivning Inkommande uppringnings-peer från Webex Call

För att visa utdata för visningskommandot har vi gjort en ny inläsning av VCUBE-2 följt av VCUBE-1, vilket gör VCUBE-1 till standby-CUBE och VCUBE-2 till aktiv CUBE

2

När som helst kommer endast en plattform att upprätthålla en aktiv registrering som lokal gateway med Webex Calling-åtkomsten SBC. Ta en titt på utdata för följande visningskommandon.

visa redundansprogramgrupp 1

visa status för sip-ua-registret 

 VCUBE-1#visa redundansprogramgrupp 1 Grupp-ID:1 Gruppnamn:LokalGateway-HA-administratörsstatus: Inget aggregerat drifttillstånd för avstängning: Min roll: Försätta peer-rollen: AKTIV peer-närvaro: Ja peer-komm: Ja-peer-förloppet startat: Ja RF-domän: BtoB-ett RF-tillstånd: RF-status i vilo läge: AKTIV VCUBE-1#visa status för sip-ua register VCUBE-1#

 VCUBE-2#visa redundansprogramgrupp 1 Grupp-ID:1 Gruppnamn:LokalGateway-HA-administratörsstatus: Inget aggregerat drifttillstånd för avstängning: Min roll: AKTIV peer-roll: STATUS för peer-närvaro: Ja peer-komm: Ja-peer-förloppet startat: Ja RF-domän: BtoB-ett RF-tillstånd: RF-status för aktiv peer: VÄNTe läge varm VCUBE-2 #Visa status för sip-ua-registrering : 200 --------------------Registrator-index  1 --------------------- Linje peer expires(sek) reg överlevnad P-Associ-URI ============================== ========================================== Hussain5091_LGU -1 48 ja normal VCUBE-2#

Från utdata ovan kan du se att VCUBE-2 är den aktiva LGW som upprätthåller registreringen med Webex Calling-åtkomst-SBC, medan utdata för ”visa sip-ua register status” är tom i VCUBE-1

3

Aktivera nu följande felsökningar på VCUBE-1

 VCUBE-1#debug ccsip icke-samtal SIP-spårning utanför dialog är aktiverad VCUBE-1#debug ccsip info SIP-samtalsinformation är aktiverad VCUBE-1#debug ccsip-meddelande

4

Simulera felöverlämning genom att utfärda följande kommando på den aktiva LGW, VCUBE-2 i det här fallet.

 VCUBE-2#redundansprogram läses in grupp 1 på nytt

Växling från AKTIV till STANDBY för LGW sker även i följande scenario, förutom CLI som listas ovan

  • När den AKTIVA routern läses in på nytt

  • När den AKTIVA routern gör en kall omstart

  • När den AKTIVA routerns RG-konfigurerade gränssnitt är avstängda för vilket spårning är aktiverat

5

Kontrollera om VCUBE-1 har registrerats med Webex Calling-åtkomst SBC. VCUBE-2 skulle ha lästs in på nytt vid det här laget.

 VCUBE-1#visa status för sip-ua register: 200 --------------------Registrator-index  1 --------------------- Linjepeer expires(sek) reg överlevnad P-Associ-URI ============================== ============================================================== Hussain5091_LGU -1 56 ja normal VCUBE-1#

VCUBE-1 är nu aktiv LGW.

6

Titta på relevant felsökningslogg på VCUBE-1 som skickar en SIP-registrering till Webex Calling VIA den virtuella IP-adressen och mottager en 200 OK.

 VCUBE-1#visa logg 9 jan 18:37:24.769: %RG_MEDIA-3-TIMERHAR GÅTT UT: RG id 1 Hej tid har upphört.9  jan 18:37:24.771: %RG_PROTCOL-5-ROLECHANGE: RG-ID 1-rollbyte från vänteläge till aktiv 9 jan 18:37:24.783: %VOICE_HA-2-SWITCHOVER_IND: Växling, från VÄNTELÄGE_HOT till AKTIVT tillstånd. 9 jan 18:37:24.783: //-1/xxxxxxxxxxxx/SIP/Info/info/4096/sip_ha_notify_active_role_event: Mottaget meddelande om aktiv roll händelse jan 9 18:37:25.758: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Skickades: REGISTRERA SIP: 40462196.cisco-bcld.com:5061 SIP/2.0 via: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK0374 Från: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 Till: <sip:Hussain5091_LGU@40462196.cisco-bcld.com> Datum: Tors, 09 Jan 2020 18:37:24 GMT-samtals-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 user-agent: Cisco-SIPGateway/IOS-16.12.02 Max-forwards: 70 timestamp: 1578595044 CSeq: 2 REGISTRERA kontakt: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls> Upphör: 240 stöds: Innehållets längd: 0 

9 jan 18:37:25.995: //-1/0000000000/SIP/Msg/ccsipDisplayMsg: Fått: SIP/2.0 401 ej auktoriserad via: SIP/2.0/TLS 198.18.1.228:5061;mottaget=173.38.218.1;branch=z9hG4bK0374;rport=4742 Från: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 Till: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1324701502-1578595045969 Datum: Tors, 09 Jan 2020 18:37:24 GMT-samtals-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 timestamp: 1578595044 CSeq: 2 Registrera WWW-autentisera; DIGEST-sfär = "BroadWorks", qop = "autentisering", nonce = "BroadWorksXk572qd01Ti58zliBW", algoritm = MD5 Content-Length: 0 

9 jan 18:37:26.000: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Skickades: REGISTRERA SIP: 40462196. Cisco-bcld.com:5061 SIP/2.0 via: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK16DC Från: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 Till: <sip:Hussain5091_LGU@40462196.cisco-bcld.com> Datum: Tors, 09 Jan 2020 18:37:25 GMT-samtals-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 user-agent: Cisco-SIPGateway/IOS-16.12.02 Max-forwarder: 70 timestamp: 1578595045 CSeq: 3 REGISTRERA kontakt: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls> Upphör: 240 stöds: sökväg behörighet: Digest användarnamn="Hussain1076_LGU",realm="BroadWorks",uri="sips:40462196.cisco-bcld.com:5061",response="b6145274056437b9c07f7ecc08ebdb02",nonce="BroadWorksXk572qd01Ti58z1iBW",cnonce="3E0E2C4D",qop=auth,algorithm=MD5,nc=00000001 Innehållslängd: 0 

9 jan 18:37:26.190: //1/0000000000/SIP/Msg/ccsipDisplayMsg:  Fått: SIP/2.0 200 OK Via: SIP/2.0/TLS 198.18.1.228:5061;mottaget=173.38.218.1;branch=z9hG4bK16DC;rport=4742 Från: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 Till: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1897486570-1578595-46184 Samtals-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 timestamp: 1578595045 CSeq: 3 REGISTRERA kontakt: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>;expires=120;q=0,5 Tillåt-händelser: samtal-info, linje – över, dialog, meddelande – sammanfattning, as-event, x-broadworks-hotell, x-broadworks-Call-Center-status, konferens innehåll – längd: 0