- Domů
- /
- Článek
Implementace vysoké dostupnosti CUBE jako místní brány
Místní brána (LGW) je jedinou možností, jak poskytnout zákazníkům služby Cisco Webex Calling přístup do místní sítě PSTN. Cílem tohoto dokumentu je pomoci vám při vytváření konfigurace místní brány pomocí CUBE s vysokou dostupností, aktivních nebo pohotovostních CUBEpro stavové převzetí aktivních hovorů při selhání.
Základní principy
Požadavky
Než nasadíte CUBE HA jako místní bránu pro službu Webex Calling, ujistěte se, že důkladně rozumíte následujícím konceptům:
Redundance typu box-to-box vrstvy 2 s CUBE Enterprise pro zachování stavových hovorů
Pokyny pro konfiguraci uvedené v tomto článku předpokládají vyhrazenou platformu místní brány bez existující hlasové konfigurace. Pokud je stávající podnikové nasazení CUBE upraveno tak, aby také využívalo funkci místní brány pro službu Cisco Webex Calling, věnujte velkou pozornost konfiguraci, která zajistí, že stávající toky hovorů a funkce nebudou přerušeny, a ujistěte se, že dodržujete požadavky na návrh CUBE HA.
Hardwarové a softwarové komponenty
CUBE HA jako místní brána vyžaduje IOS-XE verze 16.12.2 nebo novější a platformu, na které jsou podporovány funkce CUBE HA i LGW.
Příkazy a protokoly show v tomto článku jsou založeny na minimální verzi softwaru Cisco IOS-XE 16.12.2 implementovaném na vcube (CSR1000v).
Referenční materiál
Zde je několik podrobných konfiguračních příruček CUBE HA pro různé platformy:
CSR 1000v (vcube)— https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-CSR1000v.html
Preferovaná architektura Cisco pro Cisco Webex Calling – https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Přehled řešení Webex Calling
Cisco Webex Calling je nabídka spolupráce, která poskytuje cloudovou alternativu k místní telefonní službě ústředny PBX s více možnostmi sítě PSTN pro zákazníky.
Tento článek se zaměřuje na nasazení místní brány (znázorněné níže). Přenosový spoj místní brány (místní síť PSTN) ve službě Webex Calling umožňuje připojení ke službě PSTN vlastněné zákazníkem. Poskytuje také připojení k místnímu nasazení ústředny IP, jako je Cisco Unified CM. Veškerá komunikace do a z cloudu je zabezpečena přenosem TLS pro SIP a SRTP pro média.
Níže uvedený obrázek zobrazuje nasazení služby Webex Calling bez existující ústředny IP a lze jej použít pro jedno nasazení nebo vícemístné nasazení. Konfigurace uvedená v tomto článku je založena na tomto nasazení.
Redundance systému box-to-box vrstvy 2
Redundance CUBE HA vrstvy 2 box-to-box využívá protokol infrastruktury Redundancy Group (RG) k vytvoření aktivního/pohotovostního páru routerů. Tento pár sdílí stejnou virtuální IP adresu (VIP) napříč svými příslušnými rozhraními a neustále si vyměňuje stavové zprávy. Informace o relaci CUBE jsou kontrolovány přes dvojice routerů, což umožňuje pohotovostnímu směrovači převzít všechny odpovědnosti za zpracování hovorů CUBE okamžitě, pokud aktivní směrovač přestane fungovat, což má za následek zachování stavu signalizace a médií.
Kontrola ukazování je omezena na propojené hovory s pakety médií. Probíhající hovory nejsou kontrolovány směrované (například stav zkoušení nebo vyzvánění).
V tomto článku bude CUBE HA odkazovat na redundanci CUBE High Availability (HA) Layer 2 Box-to-Box (B2B) pro zachování stavových hovorů
Od verze IOS-XE 16.12.2 lze CUBE HA nasadit jako místní brána pro nasazení přenosového spoje Cisco Webex Calling (místní síť PSTN) a v tomto článku se budeme zabývat návrhy a konfiguracemi. Na tomto obrázku se zobrazuje typické nastavení HA CUBE jako místní brána pro nasazení přenosového spoje Cisco Webex Calling.
Infra komponenta skupiny redundance
Komponenta Redundancy Group (RG) Infra poskytuje podporu komunikační infrastruktury typu box-to-box mezi oběma CUBEa vyjednává konečný stabilní stav redundance. Tato součást také poskytuje:
Protokol podobný HSRP, který vyjednává konečný stav redundance pro každý router výměnou zpráv keepalive a hello mezi dvěma CUBEy (přes ovládací rozhraní) – Gigabitethernet3 na obrázku výše.
Transportní mechanismus pro kontrolu stavu signalizace a médií pro každé volání z aktivního směrovače do pohotovostního režimu (přes datové rozhraní) – Gigabitethernet3 na obrázku výše.
Konfigurace a správa Virtual IP (VIP) rozhraní pro dopravní rozhraní (více dopravních rozhraní lze konfigurovat pomocí stejné RG skupiny) – Gigabitethernet 1 a 2 jsou považovány za dopravní rozhraní.
Tato RG komponenta musí být speciálně nakonfigurována pro podporu hlasové B2B HA.
Správa virtuálních IP (VIP) adres pro signalizaci i média
B2B HA spoléhá na VIP k dosažení redundance. VIP a přidružená fyzická rozhraní na obou CUBEv páru CUBE HA musí být umístěna na stejné podsíti LAN. Pro podporu hlasové B2B HA je nutná konfigurace VIP a vazba VIP rozhraní na konkrétní hlasovou aplikaci (SIP). Externí zařízení, jako je Unified CM, přístupový SBC služby Webex Calling, poskytovatel služeb nebo proxy, používají jako cílovou IP adresu VIP pro hovory procházející směrovači CUBE HA. Z hlediska služby Webex Calling tedy páry CUBE HA fungují jako jediná místní brána.
Informace o signalizaci hovorů a relaci RTP zavedených hovorů jsou kontrolovány z aktivního směrovače do pohotovostního směrovače. Když Aktivní směrovač klesne, převezme jej pohotovostní směrovač a pokračuje vpřed datový proud RTP, který byl dříve směrován prvním směrovačem.
Hovory v přechodném stavu v době převzetí služeb při selhání nebudou po přepnutí zachovány. Například hovory, které ještě nejsou plně zavedeny nebo jsou v procesu změny pomocí funkce přepojování nebo přidržení hovorů. Navázané hovory mohou být po přepnutí odpojeny.
Pro použití CUBE HA jako místní brány pro stavové převzetí služeb při selhání volání existují následující požadavky:
CUBE HA nemůže mít současně umístěna rozhraní TDM nebo analogová rozhraní
Gig1 a Gig2 jsou označovány jako rozhraní provozu (SIP/RTP) a Gig3 je Redundancy Group (RG) Control/data interface
Do stejné domény vrstvy 2 nelze umístit více než 2 páry CUBE HA, jeden s ID skupiny 1 a druhý s ID skupiny 2. Pokud nakonfigurujete 2 páry HA se stejným ID skupiny, rozhraní RG Control/Data musí patřit do různých domén vrstvy 2 (vlan, samostatný přepínač)
Port kanál je podporován pro rozhraní RG Control/data a provoz
Veškerá signalizace/média jsou získávána z/na virtuální IP adresu
Kdykoli je platforma znovu načtena ve vztahu CUBE-HA, vždy se spustí jako pohotovostní režim
Nižší adresa pro všechna rozhraní (Gig1, Gig2, Gig3) by měla být na stejné platformě
Identifikátor rozhraní redundance, rii by měl být jedinečný pro kombinaci párů/rozhraní na stejné vrstvě 2
Konfigurace na obou CUBEech musí být shodná, včetně fyzické konfigurace a musí být spuštěna na stejném typu platformy a verzi IOS-XE
Loopback rozhraní nelze použít jako vázání, protože jsou vždy nahoře
Rozhraní pro vícenásobný provoz (SIP/RTP) (Gig1, Gig2) vyžadují konfiguraci sledování rozhraní
CUBE-HA není podporována přes příčné kabelové připojení pro RG-ovládání/datové spojení (Gig3)
Obě platformy musí být identické a musí být připojeny přes fyzický Spínač napříč všemi podobnými rozhraními, aby CUBE HA fungovala, tj. GE0/0/0 z CUBE-1 a CUBE-2 musí být ukončeny stejným přepínačem a tak dále.
Nelze přímo ukončit WAN na CUBEani na jedné straně Data HA
Obě aktivní/pohotovostní zařízení musí být ve stejném datovém centru.
Pro redundanci je nutné používat samostatné rozhraní L3 (RG Control/data, Gig3). Rozhraní používané pro provoz tedy nelze použít pro HA keepalives a checkpointování
Při převzetí služeb při selhání projde dříve aktivní CUBE designem znovunačtením, zachováním signalizace a médií
Konfigurovat redundanci pro oba CUBESy
Je nutné nakonfigurovat redundanci typu box-to-box vrstvy 2 na obou souborech CUBEurčených k použití ve dvojici HA pro vyvolání virtuálních IPS.
1 | Nakonfigurujte sledování rozhraní na globální úrovni pro sledování stavu rozhraní.
Funkce Track CLI se používá v RG ke sledování stavu rozhraní hlasového provozu, takže aktivní trasa bude zcela aktivní po ukončení provozu rozhraní. | ||
2 | Nakonfigurujte RG pro použití s VoIP HA v dílčím režimu redundance aplikace.
Zde je vysvětlení polí použitých v této konfiguraci:
| ||
3 | Povolit redundanci box-to-box pro aplikaci CUBE. Konfigurace RG z předchozího kroku níže
redundancy-group 1 – Přidání a odebrání tohoto příkazu vyžaduje opětovné načtení, aby se projevila aktualizovaná konfigurace. Platformy znovu načteme, až bude použita veškerá konfigurace. | ||
4 | Nakonfigurujte rozhraní Gig1 a Gig2 s příslušnými virtuálními IPS podle obrázku níže a použijte identifikátor rozhraní redundance (rii)
Zde je vysvětlení polí použitých v této konfiguraci:
| ||
5 | Uložte konfiguraci první CUBE a znovu ji načtěte. Platforma pro poslední načtení je vždy pohotovostní Režim.
Po úplném spuštění VCUBE-1 uložte konfiguraci VCUBE-2 a znovu ji načtěte.
| ||
6 | Ověřte, zda konfigurace box-to-box funguje podle očekávání. Příslušný výstup je zvýrazněn tučně. Reload VCUBE-2 poslední a podle posouzení návrhu; platforma pro reload poslední bude vždy pohotovostní.
|
Konfigurace místní brány v obou souborech CUBE
V našem příkladu konfigurace používáme následující informace o přenosovém spoji z centra Control Hub k sestavení konfigurace místní brány na platformách VCUBE-1 a VCUBE-2. Uživatelské jméno a heslo pro toto nastavení jsou následující:
Uživatelské jméno: Paroháč1076_LGU
Heslo: Číslo OV12M
1 | Před použitím v přihlašovacích údajích nebo sdílených tajemstvích se ujistěte, že je pro heslo vytvořen konfigurační klíč s níže uvedenými příkazy. Hesla typu 6 jsou šifrována pomocí šifry AES a tohoto uživatelem definovaného konfiguračního klíče.
Zde je konfigurace místní brány, která se použije na obě platformy na základě výše uvedených parametrů prostředí Control Hub, a to uložení a opětovné načtení. Přihlašovací údaje SIP Digest z centra Control Hub jsou zvýrazněny tučně.
Pro zobrazení výstupu příkazu show jsme znovu načetli VCUBE-2 následovaný VCUBE-1, takže VCUBE-1 je pohotovostní CUBE a VCUBE-2 aktivní CUBE |
2 | V daném okamžiku zachová aktivní registraci jako místní brána s přístupovým serverem SBC služby Webex Calling pouze jedna platforma. Podívejte se na výstup následujících příkazů show. zobrazit skupinu aplikací redundance 1 zobrazit stav registru sip-ua
Z výše uvedeného výstupu můžete vidět, že VCUBE-2 je aktivní LGW udržující registraci pomocí přístupového SBC služby Webex Calling, zatímco výstup „show sip-ua register status“ je ve VCUBE-1 prázdný. |
3 | Nyní povolte následující ladění na VCUBE-1
|
4 | Simulovat převzetí služeb při selhání spuštěním následujícího příkazu na aktivní LGW, VCUBE-2 v tomto případě.
K přepnutí z ACTIVE do LGW pohotovostního režimu dochází i v následujícím scénáři kromě výše uvedeného rozhraní příkazového řádku
|
5 | Zkontrolujte, zda se služba VCUBE-1 zaregistrovala u přístupového SBC služby Webex Calling. VCUBE-2 by už byla načtena.
VCUBE-1 je nyní aktivní LGW. |
6 | Podívejte se na příslušný protokol ladění ve službě VCUBE-1, který odesílá SIP REGISTR do služby Webex Calling PROSTŘEDNICTVÍM virtuální IP a přijímá 200 OK.
|