- Ana Sayfa
- /
- Makale
CUBE yüksek kullanılabilirliğini Yerel Ağ Geçidi Olarak uygulama
Yerel Ağ Geçidi (LGW), Cisco Webex Calling müşterileri için iş yeri temelli PSTN erişimi sağlamak için tek seçenektir. Bu belgenin amacı, aktif çağrıların durum bilgisiyle yük devri için yüksek kullanılabilirlikli CUBE, aktif veya beklemedeki CUBE'leri kullanarak Yerel Ağ Geçidi yapılandırması oluşturmanıza yardımcı olmaktır.
Temel Bilgiler
Cisco WebEx Meeting Center Yapılandırma Kılavuzları
CUBE HA'yı Webex Calling için yerel ağ geçidi olarak dağıtmadan önce aşağıdaki kavramları iyice anladığınızdan emin olun:
Durum bilgisiyle çağrı muhafaza etmek için 2. katman kutudan kutuya yedeklilik
Bu makalede verilen yapılandırma yönergelerinde, herhangi bir ses yapılandırmasının mevcut olmadığı özel bir yerel ağ geçidi platformunun olduğu varsayılmıştır. Mevcut bir CUBE işletme dağıtımının, Cisco Webex Calling için yerel ağ geçidi işlevini kullanacak biçimde değiştirilmesi durumunda, mevcut çağrı akış ve işlevlerinin kesintiye uğramaması için uygulanan yapılandırmaya özellikle dikkat edin ve CUBE HA tasarım gereksinimlerine uyduğunuzdan emin olun.
Donanım ve Yazılım Bileşenleri
Yerel ağ geçidi olarak CUBE HA, IOS-XE 16.12.2 veya sonraki bir sürümü ile CUBE HA ve LGW işlevlerinin her ikisinin de desteklendiği bir platform gerektirir.
Bu makalede gösterilen komutlar ve kayıtlar için vCUBE (CSR1000v) üzerinde minimum Cisco IOS-XE 16.12.2 yazılım sürümü kullanılmıştır.
Referans Materyali
Aşağıda çeşitli platformlar için ayrıntılı CUBE HA yapılandırma kılavuzları verilmiştir:
ISR 4K serisi— https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-ISR4K.html
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 Webex Calling için Cisco'nun Tercih Ettiği Mimari— https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Webex Calling Çözümüne Genel Bakış
Cisco Webex Calling, müşteriler için çoklu PSTN seçeneğiyle iş yeri PBX telefonu hizmetine çok kiracılı, bulut temelli bir alternatif sunan bir iş birliği hizmetidir.
Bu makalenin konusu (aşağıda verilen) Yerel Ağ Geçidi dağıtımıdır. Webex Calling'deki yerel ağ geçidi (İş Yeri Temelli PSTN) santralli, müşterinin sahip olduğu PSTN hizmetine bağlantı kurulmasına olanak tanır. Bunun yanında, Cisco Unified CM gibi iş yeri IP PBX dağıtımlarına bağlantı sağlar. Buluttan gelen ve buluta giden tüm iletişimin güvenliği, SIP ve ortam için SRTP için TLS taşıma kullanılarak sağlanır.
Aşağıdaki şekilde, herhangi bir IP PBX'in mevcut olmadığı ve tek veya çok siteli bir dağıtım için geçerli bir Webex Calling dağıtımı görülmektedir. Bu makalede açıklanan yapılandırma, bu dağıtım üzerine kuruludur.
2. Katman Kutudan Kutuya Yedeklilik
CUBE HA 2. katman kutudan kutuya yeterlilik, Yedeklilik Grubu (RG) altyapısı protokolünü kullanarak aktif/beklemede bir yönlendirici çifti oluşturur. Bu çift, kendi arayüzleri genelinde aynı sanal IP adresini (VIP) paylaşır ve sürekli olarak durum mesajı alışverişi yapar. CUBE oturum bilgileri yönlendirici çifti arasında kontrol noktalarından geçerek, aktif yönlendiricinin servis dışı kalması durumunda beklemedeki yönlendiricinin tüm CUBE çağrı işleme sorumluluklarını derhal devralarak sinyal ve ortam öğelerinin durum bilgisiyle muhafaza edilmesine olanak tanır.
Kontrol noktasından geçme, ortam paketli bağlı çağrılarla sınırlıdır. Aktarma durumundaki (örneğin, deneme veya çalma durumu) çağrılar kontrol noktasından geçmez.
Bu makalede CUBE HA, durum bilgisiyle çağrı muhafaza etmek için CUBE Yüksek Kullanılabilirlikli (HA) 2. Katman Kutudan Kutuya (B2B) yedekliliği ifade edecektir.
IOS-XE 16.12.2 sürümünden itibaren CUBE HA, Cisco Webex Calling santrali (İş Yeri Temelli PSTN) için Yerel Ağ Geçidi olarak dağıtılabilecek olup, bu makalede tasarım ve yapılandırma konularını ele alacağız. Bu şekilde, Cisco Webex Calling santral dağıtımı için Yerel Ağ Geçidi olarak tipik bir CUBE HA kurulumu verilmiştir.
Yedeklilik Grubu Altyapı Bileşeni
Yedeklilik Grubu (RG) Altyapı bileşeni, iki CUBE arasında kutudan kutuya iletişim altyapısı sağlar ve son kararlı yedeklilik durumunu anlaşmasını yapar. Bu bileşen ayrıca şunları sağlar:
İki CUBE arasında (kontrol arayüzü üzerinden) -yukarıdaki şekilde GigabitEthernet3- etkin tutma ve merhaba mesajı alışverişi yaparak her bir yönlendirici için son yedeklilik durumu anlaşması yapan HSRP benzeri bir protokol.
Her bir çağrı için aktif yönlendiriciden beklemedeki yönlendiriciye (veri arayüzü yoluyla) -yukarıdaki şekilde GigabitEthernet3- ortam kontrol noktasından geçirme ve sinyal gönderme işlemleri için bir taşıma mekanizmasıdır.
Sanal IP (VIP) arayüzünün trafik arayüzleri için yapılandırılması ve yönetilmesi (çoklu trafik arayüzleri aynı RG grubu kullanılarak yapılandırılabilir). GigabitEthernet 1 ve 2, trafik arayüzü olarak kabul edilir.
Bu RG bileşeninin sesli B2B HA desteklemesi için özellikle yapılandırılması gerekir.
Sinyal Gönderme ve Ortam için Sanal IP (VIP) Adresi Yönetimi
B2B HA yedeklilik için VIP kullanır. CUBE HA çiftindeki her iki CUBE üzerindeki VIP ve ilişkili fiziksel arayüzlerinin aynı LAN alt ağında olması gerekir. Ses B2B HA desteği için VIP yapılandırması ve VIP arayüzünün belirli bir ses uygulamasına (SIP) bağlanması zorunludur. Unified CM, Webex Calling erişimi SBC'si, hizmet sağlayıcı veya proxy gibi harici hizmetler, CUBE HA yönlendiricilerden geçebilecek çağrılar için hedef IP adresi olarak VIP kullanır. Dolayısıyla, Webex Calling açısından, CUBE HA çiftleri tek bir yerel ağ geçidi olarak davranır.
Çağrı sinyali gönderme ve bağlantısı kurulmuş çağrıların RTP oturumu bilgileri, aktif yönlendiriciden beklemedeki yönlendiriciye doğru kontrol noktasından geçirilir. Aktif yönlendirici devre dışı kaldığında, Beklemedeki kullanıcı devreye girer ve daha önce ilk yönlendiricinin yönlendirdiği RTP akışını yönlendirmeye devam eder.
Yük devretme sırasında geçici durumda olan çağrılar, geçiş sonrasında muhafaza edilmez. Bunlardan bazıları, bağlantısı henüz tam kurulmamış ya da aktarma veya bekletme durumunda olan çağrılardır. Geçiş sonrasında, bağlantısı kurulmuş çağrıların bağlantısı kesilebilir.
CUBE HA'nın çağrıların durum bilgisiyle yük devri için yerel ağ geçidi olarak kullanılması aşağıdaki gereksinimlere tabidir:
CUBE HA'nın TDM veya analog arayüzleri bir arada olamaz
Gig1 ve Gig2 trafik (SIP/RTP) arayüzleri, Gig3 ise Yedeklilik Grubu (RG) Kontrol/veri arayüzü olarak bilinir.
Aynı 2. katman etki alanına, biri grup kimliği 1, diğeri grup kimliği 2 ile olmak üzere en fazla 2 CUBE HA çifti yerleştirilebilir. 2 HA çiftinin aynı grup kimliğiyle yapılandırılması durumunda, RG Kontrol/Veri arayüzlerinin farklı 2. katman etki alanlarına (vlan, ayrı anahtar) ait olması gerekir
Hem RG Kontrol/veri arayüzü, hem de trafik arayüzü için port kanalı desteklenir
Tüm sinyal/ortam gönderimleri Sanal IP Adresine/Sanal IP Adresinden yapılır
Bir platform CUBE-HA ilişkisinde her yeniden yüklendiğinde, mutlaka Bekleme konumunda olarak başlar
Tüm arayüzler için düşük adres (Gig1, Gig2, Gig3) aynı platformda olmalıdır
Yedeklilik Arayüzü Tanımlayıcısı (RII), aynı 2. Katman üzerindeki bir çift/arayüz kombinasyonu için benzersiz olmalıdır
Her iki CUBE üzerindeki konfigürasyon, fiziksel konfigürasyon dahil olmak üzere birbiriyle aynı ve aynı tür platform ve IOS-XE sürümüyle çalışmalıdır
Loopback arayüzleri her zaman devrede olduğundan, bağlama için kullanılamaz
Çoklu trafik (SIP/RTP) arayüzlerinin (Gig1, Gig2) yapılandırılması için arayüz takibi gerekir
CUBE-HA, RG-kontrol/veri bağlantısı (Gig3) için çapraz kablo üzerinden desteklenmez
CUBE HA’nın çalışması için her iki platformun da aynı olması ve tüm benzer arayüzler arasında fiziksel bir Anahtar ile bağlanması gereklidir. Örneğin, CUBE-1 ve CUBE-2 için GE0/0/0 aynı anahtarda sonlanmalıdır.
Doğrudan CUBE'lerde sonlandırılmış WAN veya iki tarafın birinde Veri HA'sı olamaz
Aktif/Bekleme aynı veri merkezinde olmalıdır
Yedeklilik için ayrı L3 arayüzü (RG Kontrol/veri, Gig3) kullanılması zorunludur. Yani trafik için kullanılan arayüz, HA etkin tutma ve kontrol noktasından geçirme işlemleri için kullanılamaz
Yük devrinin ardından, daha önce etkin olan CUBE, tasarımı gereği sinyal ve ortam gönderimini muhafaza ederek yeniden yüklenir
Her İki CUBE Üzerinde Yedekliliği Yapılandırma
Sanal IP'leri etkinleştirmek için HA çiftinde kullanılması amaçlanan her iki CUBE üzerinde 2. katman kutudan kutuya yedekliliği yapılandırmanız gerekir.
1 | Arayüzün durumunu takip etmek için genel düzeyde arayüz takibini yapılandırın.
Trafik arayüzünün devre dışı kalmasının ardından etkin rolünden çıkması için ses trafiği arayüz durumunu takip etmek için RG'de CLI takibi kullanılır. | ||
2 | RG'yi uygulama yedeklilik alt modunda VoIP HA ile kullanmak için yapılandırın.
Bu yapılandırmada kullanılan alanların açıklaması aşağıda verilmiştir:
| ||
3 | CUBE uygulaması için kutudan kutuya yedekliliği etkinleştirin. Şurada önceki adımdan RG'yi yapılandırın:
redundancy-group 1: Bu komutun eklenmesi ve kaldırılması, güncellenen yapılandırma için yeniden yüklemenin geçerli olmasını gerektirir. Tüm yapılandırma uygulandıktan sonra platformları yükleyeceğiz. | ||
4 | Gig1 ve Gig2 arayüzlerini aşağıda gösterildiği gibi kendi sanal IP'leriyle yapılandırın ve yedeklilik arayüzü tanımlayıcısını (RII) uygulayın
Bu yapılandırmada kullanılan alanların açıklaması aşağıda verilmiştir:
| ||
5 | İlk CUBE yapılandırmasını kaydedip yeniden yükleyin. En son yeniden yüklenecek platform her zaman Bekleme konumunda olacaktır.
VCUBE-1 tamamen başlatıldıktan sonra VCUBE-2'nin yapılandırmasını kaydedip yeniden yükleyin.
| ||
6 | Kutudan kutuya yapılandırmanın beklendiği gibi çalıştığını doğrulayın. İlgili çıktı kalın yazılarak vurgulanmıştır. VCUBE-2'yi son olarak ve tasarım konularına uygun bir biçimde yeniden yükledik. Son yüklenen platform her zaman Bekleme konumunda olacaktır.
|
Her İki CUBE Üzerinde Yerel Ağ Geçidi Yapılandırma
Yapılandırma örneğimizde, hem VCUBE-1, hem de VCUBE-2 platformunda Yerel Ağ Geçidi yapılandırmasını oluşturmak için Control Hub'dan aşağıdaki santral bilgilerini kullanıyoruz. Bu yapılandırmanın kullanıcı adı ve parolası şöyle:
Kullanıcı adı: Hüseyin1076_LGU
Parola: lOV12MEaZx
1 | Parolanın kimlik bilgilerinde veya paylaşılan şifrelerde kullanılabilmesi için aşağıdaki komutlarla parola için bir yapılandırma anahtarı oluşturulduğundan emin olun. Tip 6 parolalar, AES şifre ve kullanıcı tanımlı yapılandırma anahtarı kullanılarak şifrelenir.
Burada, yukarıda gösterilen Control Hub parametreleri temel alınarak her iki platforma uygulanacak Yerel Ağ Geçidi yapılandırması verilmiştir. Kaydedip yeniden yükleyin. Control Hub'dan gelen SIP Özeti kimlik bilgileri kalın yazılarak vurgulanmıştır.
Komut gösterme çıktısını görüntülemek için VCUBE-2 ve ardından VCUBE-1'i yeniden yükleyerek, VCUBE-1'nin bekleme konumundaki CUBE, VCUBE-2'nin ise aktif CUBE olmasını sağladık. |
2 | Herhangi bir zamanda, yalnızca bir platformun Webex Calling erişim SBC'siyle Yerel Ağ Geçidi olarak aktif bir kaydı olacaktır. Aşağıdaki komut gösterme çıktılarına göz atın. show redundancy application group 1 sip-ua kayıt durumunu göster
Yukarıdaki çıktıda, VCUBE-2 Webex Calling erişim SBC'li kaydı olan aktif LGW olurken, VCUBE-1'de "show sip-ua register status" çıktısının boş olduğunu görebilirsiniz. |
3 | Şimdi VCUBE-1'de aşağıdaki hata ayıklamaları etkinleştirin
|
4 | Bu durumda VCUBE-2 olmak üzere aktif LGW üzerinde aşağıdaki komutu çalıştırarak yük devri simülasyonu yapın.
Yukarıda gösterilen CLI'nin yanı sıra aşağıdaki senaryoda AKTİF LGW'dan BEKLEME konumundaki LGW'ya geçiş gerçekleşir.
|
5 | VCUBE-1'in Webex Calling erişim SBC'siyle kaydolup kaydolmadığını görmek için kontrol edin. VCUBE-2 şimdiye kadar yüklenmiş olmalıdır.
Şu anda aktif LGW, VCUBE-1'dir. |
6 | Sanal IP üzerinden Webex Calling'e SIP KAYDI gönderen ve 200 OK alan VCUBE-1 üzerindeki ilgili hata ayıklama kaydını inceleyin.
|