- 首頁
- /
- 文章
將 CUBE 高可用性實作為本機閘道
本機閘道 (LGW) 是為 Cisco Webex Calling 客戶提供內部部署型 PSTN 存取的唯一選項。 本文件的目的是協助您建立本機閘道設定,使用 CUBE高可用性、作用中或待命 CUBE 來實現作用中通話的有狀態故障轉移。
基礎
先決條件
在將 CUBE HA 部署為 Webex Calling 的本機閘道之前,請確保您已深入瞭解下列概念:
針對具狀態呼叫保留的 CUBE 企業第二層裝置到裝置備援
本文中提供的設定指導方針採用專用的本機閘道平台,且未設定任何現有的語音。 如果正在修改現有的 CUBE 企業部署以同時針對 Cisco Webex Calling 利用本機閘道功能,請密切注意已套用的設定,以確保現有的通話流程和功能不會中斷,並確保符合 CUBE HA 的設計需求。
軟硬體元件
CUBE HA 即本機閘道需要 IOS-XE 16.12.2 版或更高版本以及一個同時支援 CUBE HA 和 LGW 功能的平台。
本文中的顯示指令和日誌基於在 vCUBE (CSR1000v) 上實作的最低軟體版本 Cisco IOS-XE 16.12.2。
參考資料
以下是針對各種平台的一些詳細的 CUBE HA 設定指南:
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
Cisco 偏好的架構(針對 Cisco Webex Calling)— https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Webex Calling 解決方案概觀
Cisco Webex Calling 是一種協同作業產品,該產品會為內部部署 PBX 電話服務提供多租戶雲端型替代方案,並為客戶提供多個 PSTN 選項。
本機閘道部署(如下所示)是本文的重點。 使用 Webex Calling 中的本機閘道(內部部署型 PSTN)幹線可以連線至客戶擁有的 PSTN 服務。 它還會提供與內部部署 IP PBX 部署(例如 Cisco Unified CM)的連線。 透過針對 SIP 使用 TLS 傳輸和針對媒體使用 SRTP,進出雲端的所有通訊都會得到保護。
下圖顯示的 Webex Calling 部署不包含任何現有的 IP PBX,適用於單一或多網站部署。 本文所述的設定基於此部署。
第二層裝置到裝置備援
CUBE HA 第二層裝置到裝置備援使用備援群組 (RG) 基礎結構通訊協定來形成作用中/待命路由器配對。 此配對在其各自的介面之間共用相同的虛擬 IP 位址 (VIP),並持續交換狀態訊息。 在路由器配對之間對 CUBE 階段作業資訊進行抽點檢查,使待命路由器能夠在作用中路由器無法服務時,立即接管所有 CUBE 通話處理職責,從而產生具狀態的訊號和媒體保留。
抽點檢查僅限於帶有媒體封包的連線通話。 不會對傳輸中的通話進行抽點檢查(例如,正在聯絡或正在響鈴狀態)。
在本文中,CUBE HA 是指針對具狀態呼叫保留的 CUBE 高可用性 (HA) 第二層裝置到裝置 (B2B) 備援
從 IOS-XE 16.12.2 開始,可以將 CUBE HA 部署為 Cisco Webex Calling 幹線(內部部署型 PSTN)的本機閘道,本文將對設計注意事項和設定進行介紹。 此圖顯示的是作為 Cisco Webex Calling 幹線部署之本機閘道的一般 CUBE HA 設定。
備援群組基礎結構元件
備援群組 (RG) 基礎結構元件會提供兩個 CUBE 之間的裝置到裝置通訊基礎結構支援,並協商最終穩定的備援狀態。 此元件還會提供:
一個與 HSRP 類似的通訊協定,可透過在兩個 CUBE 之間交換 keepalive 和 hello 訊息,來協商每個路由器的最終備援狀態(透過控制介面)— 上圖中的 GigabitEthernet3。
一種傳輸機制,用於對從作用中到待命路由器的每個通話的訊號和媒體狀態進行抽點檢查(透過資料介面)— 上圖中的 GigabitEthernet3。
流量介面的虛擬 IP (VIP) 介面設定和管理(可以使用相同的 RG 群組設定多個流量介面)— GigabitEthernet 1 和 2 被視為流量介面。
必須專門設定此 RG 元件才能支援語音 B2B HA。
訊號和媒體的虛擬 IP (VIP) 位址管理
B2B HA 依賴於 VIP 來實現備援。 CUBE HA 配對中兩個 CUBE 上的 VIP 和關聯的實體介面必須駐留在相同的 LAN 子網路上。 必須設定 VIP 並將 VIP 介面連結至特定語音應用程式 (SIP),才能支援語音 B2B HA。 外部裝置(例如,Unified CM、Webex Calling 存取 SBC、服務提供者或 Proxy)使用 VIP 作為遍訪 CUBE HA 路由器之通話的目的地 IP 位址。 因此,從 Webex Calling 的視角來看,CUBE HA 配對可充當單一的本機閘道。
從作用中路由器到待命路由器對已建立通話的通話訊號和 RTP 階段作業資訊進行抽點檢查。 當作用中路由器關閉時,待命路由器即會接管,並繼續轉發先前由第一個路由器路由的 RTP 串流。
轉換後不會保留在容錯移轉時處於暫時狀態的通話。 例如,未完全建立的通話或正在使用 transfer 或 hold 函數修改的通話。 已建立的通話在轉換後可能會中斷連線。
針對具狀態的通話容錯移轉使用 CUBE HA 作為本機閘道存在下列需求:
CUBE HA 不能讓 TDM 或類比介面位於一處
Gig1 和 Gig2 被稱為流量 (SIP/RTP) 介面,而 Gig3 是備援群組 (RG) 控制/資料介面
在同一個第二層網域中不能放置 2 個以上的 CUBE HA 配對,一個群組 id 為 1,另一個群組 id 為 2。 如果使用相同的群組 id 設定 2 個 HA 配對,則 RG 控制/資料介面必須屬於不同的第二層網域(vlan,單獨的交換器)
RG 控制/資料和流量介面都支援連接埠通道
所有訊號/媒體都會進出虛擬 IP 位址
每當在 CUBE-HA 關係中重新載入某個平台時,它總是作為「待命」啟動
所有介面(Gig1、Gig2、Gig3)的較低位址應位於相同的平台上
備援介面識別元 (rii ) 對同一個第二層上的配對/介面組合來說,應該是唯一的
兩個 CUBE 上的設定(包括實體設定)必須相同,且必須在相同的平台類型和 IOS-XE 版本上執行
回送介面不能用作連結,因為它們始終處於開啟狀態
多個流量 (SIP/RTP) 介面(Gig1、Gig2)要求設定介面追蹤
在 RG 控制/資料鏈結 (Gig3) 的交叉纜線連線上不支援 CUBE-HA
兩個平台必須相同,且必須跨所有類似介面透過 實體交換器 進行連線以便 CUBE HA 能夠運作,例如,CUBE-1 和 CUBE-2 的 GE0/0/0 必須位於相同的交換器上等等。
不能直接在 CUBE 上終止 WAN,也不能在任何一端終止資料 HA
作用中/待命都必須位於相同的資料中心內
必須針對備援(RG 控制/資料,Gig3)使用單獨的 L3 介面,亦即,用於流量的介面不能用於 HA keepalive 和抽點檢查
在容錯移轉時,先前作用中的 CUBE 會依據設計完成重新載入,從而保留訊號和媒體
在兩個 CUBE 上設定備援
您必須在要在 HA 配對中使用的兩個 CUBE 上設定第二層裝置到裝置備援,以開啟虛擬 IP。
1 | 在全域層級設定介面追蹤,以追蹤介面的狀態。
在 RG 中使用追蹤 CLI 來追蹤語音流量介面狀態,這樣在流量介面關閉後,作用中路由就會相當活躍。 | ||
2 | 在應用程式備援子模式下,設定 RG 以用於 VoIP HA。
以下是此設定中所使用欄位的說明:
| ||
3 | 為 CUBE 應用程式啟用裝置到裝置備援。 在上一步中,於以下位置設定 RG
redundancy-group 1 — 新增和移除此指令需要重新載入,更新的設定才會生效。 在套用所有設定之後,我們會重新載入平台。 | ||
4 | 為 Gig1 和 Gig2 介面設定各自的虛擬 IP(如下所示),並套用備援介面識別元 (rii)
以下是此設定中所使用欄位的說明:
| ||
5 | 儲存第一個 CUBE 的設定並重新載入它。 要最後重新載入的平台始終是「待命」。
在 VCUBE-1 完全啟動之後,儲存 VCUBE-2 的設定並重新載入它。
| ||
6 | 驗證裝置到裝置設定按預期運作。 相關輸出會以粗體反白顯示。 我們依據設計注意事項最後重新載入了 VCUBE-2;要最後重新載入的平台始終是待命。
|
在兩個 CUBE 上設定本機閘道
在範例設定中,我們使用來自 Control Hub 的下列幹線資訊,在兩個平台 VCUBE-1 和 VCUBE-2 上建立本機閘道設定。 此設定的使用者名稱和密碼如下所示:
使用者名稱: 侯賽因1076_ LGU
密碼: lOV12MEaZx
1 | 請確保先使用如下所示的指令為密碼建立設定金鑰,然後才能在認證或共用密碼中使用該金鑰。 類型 6 密碼是使用 AES 密碼和該使用者定義的設定金鑰加密的。
這是本機閘道設定,將根據上面顯示的 Control Hub 參數套用至這兩個平台,並儲存和重新載入。 來自 Control Hub 的 SIP 摘要認證會以粗體突出顯示。
為了顯示顯示指令輸出,我們重新載入了 VCUBE-2,後接 VCUBE-1,使 VCUBE-1 成為待命 CUBE,使 VCUBE-2 成為作用中 CUBE |
2 | 在任何給定時間,只有一個平台會作為本機閘道維護 Webex Calling 存取 SBC 的作用中註冊。 請查看下列顯示指令的輸出。 show redundancy application group 1 顯示 SIP-UA 註冊狀態
從上面的輸出中,您可以看到 VCUBE-2 是維護 Webex Calling 存取 SBC 註冊的作用中 LGW,而在 VCUBE-1 中 "show sip-ua register status" 的輸出為空白 |
3 | 現在,在 VCUBE-1 上啟用下列除錯
|
4 | 在此情況下,透過在作用中 LGW VCUBE-2 上發出下列指令來模擬容錯移轉。
在下列情境中,除了上面所列的 CLI 之外,還會發生從「作用中」到「待命」LGW 的轉換
|
5 | 請檢查 VCUBE-1 是否已向 Webex Calling 存取 SBC 註冊。 現在 VCUBE-2 應該已重新載入。
VCUBE-1 現在是作用中 LGW。 |
6 | 請查看 VCUBE-1 透過虛擬 IP 將 SIP REGISTER 傳送至 Webex Calling,並收到 200 OK 的相關除錯日誌。
|