I denne artikel
Grundlæggende
Konfigurer redundans på begge CUBE'er
Implementere CUBE høj tilgængelighed som lokal gateway
list-menuI denne artikel
list-menuHar du feedback?

Local Gateway (LGW) er den eksklusive løsning til at levere PSTN-adgang i det lokale miljø til Cisco Webex Calling kunder. Dette dokument hjælper dig med at konfigurere en lokal gateway ved hjælp af CUBE høj tilgængelighed med aktive CUBE'er eller standby-CUBE'er for at sikre tilstandsdygtig failover af aktive opkald.

Grundlæggende

Forudsætninger

Før du installerer Cisco Unified Border Element (CUBE) High Availability (HA) som en lokal gateway forWebex Calling, skal du sørge for, at du har en indgående forståelse af følgende begreber:

Konfigurationsretningslinjerne i denne artikel antager en dedikeret lokal gateway-platform uden eksisterende stemmekonfiguration. Hvis en eksisterende CUBE-virksomhedsinstallation ændres til også at bruge den lokale gateway-funktion tilCisco Webex Calling, skal du være opmærksom på den anvendte konfiguration for at sikre, at eksisterende opkaldsstrømme og funktionaliteter ikke afbrydes, og sørg for, at du overholder CUBE HA-designkravene.

Hardware- og softwarekomponenter

CUBE HA som lokal gateway kræver IOS-XE version 17.9.1 eller nyere og en platform, hvor både CUBE HA- og LGW-funktioner understøttes.

Show-kommandoerne og logfilerne i denne artikel er baseret på minimumsudgivelse af Cisco IOS -XE 17.9.1 implementeret på en vCube (CSR 8000v).

Referencemateriale

Her er nogle detaljerede CUBE HA-konfigurationsvejledninger til forskellige platforme:

Webex CallingLøsningsoversigt

Cisco Webex Callinger et samarbejdstilbud, der giver et skybaseret alternativ med flere lejer til lokale PBX-telefontjenester med flere PSTN-muligheder for kunder.

Den lokale gateway-implementering (repræsenteret nedenfor) er fokus for denne artikel. Trunk in med lokal gateway (lokalbaseret PSTN) Webex Calling giver mulighed for tilslutning til en kundeejet PSTN-tjeneste. Det giver også forbindelse til en lokal IP PBX-implementering, f.eks. Cisco Unified CM Al kommunikation til og fra skyen er sikret ved hjælp af TLS-transport til SIP og SRTP til medier.

Local Gateway premises-based PSTN deployment

Figuren nedenfor viser en Webex Calling udrulning uden nogen eksisterende IP PBX og kan anvendes til en enkelt installation eller en installation på flere steder. Konfigurationen beskrevet i denne artikel er baseret på denne installation.

Webex Calling deployment without IP PBX

Lag 2 boks-til-boks redundans

CUBE HA lag 2 box-to-box-redundans bruger infrastrukturprotokollen Redundancy Group (RG) til at danne et aktivt/standby-par routere. Dette par deler den samme virtuelle IP-adresse (VIP) på tværs af deres respektive grænseflader og udveksler løbende statusmeddelelser. CUBE-sessionsoplysninger kontrolleres på tværs af routerparret, hvilket gør det muligt for standbyrouteren at overtage alle CUBE-opkaldsbehandlingsansvar med det samme, hvis den aktive router går ud af drift, hvilket resulterer i tilstandsbevarelse af signalering og medier.

Kontrollpegning er begrænset til tilsluttede opkald med mediepakker. Opkald i transit er ikke markerede (f.eks. en prøve- eller ringetilstand).

I denne artikel henviser CUBE HA til CUBE High Availability (HA) Layer 2 Box-to-Box (B2B) redundans til statusfuld opkaldsbevarelse.

Fra og med IOS-XE 17.9.1 kan CUBE HA implementeres som en lokal gateway til Cisco Webex Calling trunk-implementeringer (lokalbaseret PSTN). Denne artikel vil diskutere designovervejelser og konfigurationer. Figuren viser en typisk CUBE HA-opsætning som Local Gateway til en Cisco Webex Calling trunk-installation.

A typical CUBE HA setup as Local Gateway for a Cisco Webex Calling trunk deployment

Redundansgruppe Infrakomponent

Redundancy Group (RG) Infra-komponenten leverer box-to-box-kommunikationsinfrastrukturunderstøttelse mellem de to CUBE'er og forhandler den endelige stabile redundanstilstand. Denne komponent giver også:

  • En HSRP-lignende protokol, der forhandler den endelige redundanstilstand for hver router ved at udveksle keepalive og hello meddelelser mellem de to CUB'er (via kontrolgrænsefladen) —GigabiteThernet3 i figuren ovenfor.

  • En transportmekanisme til kontrol af signalering og medietilstand for hvert opkald fra den aktive til standbyrouteren (via datagrænsefladen) —GigabiteThernet3 i figuren ovenfor.

  • Konfiguration og styring af den virtuelle IP (VIP) grænseflade til trafikgrænsefladerne (flere trafikgrænseflader kan konfigureres ved hjælp af den samme RG-gruppe) - GigabitEthernet 1 og 2 betragtes som trafikgrænseflader.

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

Virtuel IP (VIP) adressestyring til både signalering og medier

B2B HA er afhængig af VIP for at opnå redundans. VIP og tilknyttede fysiske grænseflader på begge CUBE'er i CUBE HA-parret skal være placeret på det samme LAN-undernet. Konfiguration af VIP og binding af VIP-grænsefladen til en bestemt stemmeapplikation (SIP) er obligatorisk for tale B2B HA-support. Eksterne enheder såsom Unified CM Webex Calling adgang til SBC, tjenesteudbyder eller proxy bruger VIP som destinations-IP-adresse for de opkald, der krydser gennem CUBE HA-routere. Derfor fungerer CUBE HA-parrene fra et Webex Calling synspunkt som en enkelt lokal gateway.

Opkaldssignaleringen og RTP-sessionsoplysningerne for etablerede opkald kontrolleres fra den aktive router til standbyrouteren. Når den aktive router går ned, overtager Standby-routeren og fortsætter med at videresende RTP-strømmen, der tidligere blev dirigeret af den første router.

Opkald i en forbigående tilstand på tidspunktet for failover bevares ikke efter overgangen. For eksempel opkald, der endnu ikke er fuldt etableret eller er i færd med at blive ændret med en overførsels- eller hold-funktion. Etablerede opkald kan afbrydes efter overgangen.

Følgende krav gælder for at bruge CUBE HA som en lokal gateway til tilstandsdygtig failover af opkald:

  • CUBE HA kan ikke have TDM eller analoge grænseflader samplaceret

  • Gig1 og Gig2 kaldes trafikgrænseflader (SIP/RTP), og Gig3 er Redundancy Group (RG) Control/Data Interface

  • Ikke mere end 2 CUBE HA-par kan placeres i det samme lag 2-domæne, det ene med gruppe-id 1 og det andet med gruppe-id 2. Hvis du konfigurerer 2 HA-par med samme gruppe-id, skal RG Control/Data-grænseflader tilhøre forskellige lag 2-domæner (vlan, separat switch)

  • Portkanal understøttes til både RG-kontrol/data og trafikgrænseflader

  • Alle signaler/medier hentes fra/til den virtuelle IP-adresse

  • Hver gang en platform genindlæses i et CUBE-HA-forhold, starter den altid som Standby

  • Lavere adresse for alle grænseflader (Gig1, Gig2, Gig3) skal være på samme platform

  • Redundansgrænsefladeidentifikator, rii skal være unik for en par/grænsefladekombination på det samme lag 2

  • Konfigurationen på begge CUBE'er skal være identisk inklusive fysisk konfiguration og skal køre på samme type platform og IOS-XE-version

  • Loopback-grænseflader kan ikke bruges som bind, da de altid er oppe

  • Flere trafikgrænseflader (SIP/RTP) (Gig1, Gig2) kræver, at grænsefladesporing konfigureres

  • CUBE-HA understøttes ikke via en crossover-kabelforbindelse til RG-Control/Data Link (Gig3)

  • Begge platforme skal være identiske og være forbundet via en fysisk switch på tværs af alle tilsvarende grænseflader for at CUBE HA kan fungere, dvs. GE0/0/0 af CUBE-1 og CUBE-2 skal slutte på den samme switch og så videre.

  • Kan ikke få WAN afsluttet på CUBE'er direkte eller Data HA på begge sider

  • Både Active/Standby skal være i samme datacenter

  • Det er obligatorisk at bruge separat L3-grænseflade til redundans (RG Control/Data, Gig3). dvs. grænseflade, der bruges til trafik, kan ikke bruges til HA-opbevaringslister og checkpointing

  • Ved failover gennemgår den tidligere aktive CUBE en genindlæsning efter design, hvilket bevarer signalering og medier

Konfigurer redundans på begge CUBE'er

Du skal konfigurere lag 2 box-to-box-redundans på begge CUBE'er, der er beregnet til at blive brugt i et HA-par for at få virtuelle IP'er op.

A typical CUBE HA setup as Local Gateway for a Cisco Webex Calling trunk deployment

1

Konfigurer interfacesporing på globalt niveau for at spore grænsefladens status.

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

Track CLI bruges i RG til at spore stemmetrafikgrænsefladetilstanden, så den aktive rute får sin aktive rolle, når trafikgrænsefladen er nede.

2

Konfigurer en RG til brug med VoIP HA under programredundansundertilstanden.

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å de felter, der bruges i denne konfiguration:

  • redundans — Går ind i redundanstilstand

  • applikationsredundans — Går ind i konfigurationstilstand for programredundans

  • group —G år ind i konfigurationstilstand for redundansprogramgruppe

  • name localgateway-ha — Definerer navnet på RG-gruppen

  • prioritet 100 failover-tærskel 75 — Angiver den oprindelige prioritet og failover-tærskler for en RG

  • timere forsinkelse 30 genindlæsning 60 —Konfigur erer de to gange for forsinkelse og genindlæsning

    • Forsinkelsestimer, som er mængden af tid til at forsinke RG-gruppens initialisering og rolleforhandling, efter at grænsefladen kommer op - Standard 30 sekunder. Rækkevidde er 0-10000 sekunder

    • Genindlæsning — Dette er den tid, der skal forsinkes initialisering af RG-gruppe og rolleforhandling efter en genindlæsning — Standard 60 sekunder. Rækkevidde er 0-10000 sekunder

    • Standardtimere anbefales, selvom disse timere kan justeres for at imødekomme enhver yderligere netværkskonvergensforsinkelse, der kan opstå under opstart/genindlæsning af routerne, for at garantere, at RG-protokolforhandlingen finder sted, efter at routing i netværket er konvergeret til et stabilt punkt. For eksempel, hvis det efter failover ses, at det tager op til 20 sekunder for den nye STANDBY at se den første RG HELLO-pakke fra den nye ACTIVE, skal timerne justeres til 'timers delay 60 reload 120' for at tage højde for denne forsinkelse.

  • kontrol GigabiteThernet3-protokol 1 —Konfigurerer grænsefladen, der bruges til at udveksle keepalive- og hello-meddelelser mellem de to CUBE'er, og specificerer protokolforekomsten, der vil blive knyttet til en kontrolgrænseflade og går ind i konfigurationstilstand for redundansapplikationsprotokol

  • data GigabiteThernet3 —Konfigurerer grænsefladen, der bruges til kontrol af datatrafik

  • spor —RG-gruppesporing af grænseflader

  • protokol 1 — Angiver den protokolforekomst, der skal knyttes til en kontrolgrænseflade, og går ind i konfigurationstilstand for redundansapplikationsprotokol

  • timere hellotime 3 holdtime 10 —Konfigurerer de to timere til hellotime og holdtime:

    • Hellotime- Interval mellem successive hej beskeder - Standard 3 sekunder. Rækkevidde er 250 millisekund-254 sekunder

    • Holdtid — Intervallet mellem modtagelsen af en Hello besked og formodningen om, at den afsendende router er mislykket. Denne varighed skal være større end hello-tiden - Standard 10 sekunder. Rækkevidde er 750 millisekund-255 sekunder

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

3

Aktivér box-to-box-redundans for CUBE-programmet. Konfigurer RG fra forrige trin under voice service voip. Dette gør det muligt for CUBE-applikationen at styre redundansprocessen.

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 — Tilføjelse og fjernelse af denne kommando kræver en genindlæsning for at den opdaterede konfiguration kan træde i kraft. Vi genindlæser platformene, når al konfiguration er blevet anvendt.

4

Konfigurer Gig1- og Gig2-grænsefladerne med deres respektive virtuelle IP'er som vist nedenfor, og anvend redundansgrænsefladeidentifikatoren (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å de felter, der bruges i denne konfiguration:

  • redundans rii — Konfigur erer redundansgrænsefladeidentifikatoren for redundansgruppen. Kræves for at generere en virtuel MAC-adresse (VMAC). Den samme rii ID-værdi skal bruges på grænsefladen på hver router (ACTIVE/STANDBY), der har den samme VIP.

    Hvis der er mere end et B2B-par på det samme LAN, SKAL hvert par have unikke rii-ID 'er på deres respektive grænseflader (for at forhindre kollision). Kom mandoen vis redundansapplikationsgruppe alle skal angive de korrekte lokale og peer-oplysninger.

  • redundansgruppe 1 — Associerer grænsefladen med redundansgruppen oprettet i trin 2 ovenfor. Konfigurer RG-gruppen såvel som VIP tildelt denne fysiske grænseflade.

    Det er obligatorisk at bruge en separat grænseflade til redundans, det vil sige, at grænsefladen, der bruges til taletrafik, ikke kan bruges som kontrol- og datagrænseflade, der er specificeret i trin 2 ovenfor. I dette eksempel bruges Gigabit interface 3 til RG-kontrol/data

5

Gem konfigurationen af den første CUBE og genindlæs den.

Platformen, der skal genindlæses sidst, er altid Standby.

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

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

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

Kontroller, at box-to-box-konfigurationen fungerer som forventet. Relevant output fremhæves med fed skrift.

Vi genindlæste VCUBE-2 sidst og i henhold til designovervejelserne; platformen, der skal genindlæses sidst, vil altid 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#

Fortsæt derefter med den lokale gateway-konfiguration (registreringsbaseret eller certifikatbaseret) på begge HA CUBE'er. Se Konfigurere lokal gateway på Cisco IOS XE for Webex Calling.

Var denne artikel nyttig?
Var denne artikel nyttig?