10 Mbps yarı çift yönlü telefon sistemi ile mimarlık ağı


10

Geçerli yapılandırma

Aşağıdaki şema mevcut ağ mimarimizi göstermektedir. 10 MB yarı çift yönlü çalışan (diyagramın sağ üst köşesi) TalkSwitch telefon sistemleri hariç, tüm bağlantılar 100 Mbps tam çift yönlü çalışır. TalkSwitch kutularının her biri 8 analog ve 8 IP tabanlı telefon bağlantısı sağlar, böylece toplam 16 analog ve 16 IP tabanlı telefona sahip olabiliriz.

Not: Dört HP ProCurve 2524 yönetilen anahtar, ayrı VLAN'larla yapılandırılmamıştır.

Her iki anahtarın, hem TalkSwitch kutularının hem de HQ'muzdaki RV082 VPN yönlendiricimize bağlı kablosuz köprüün performans etkisinden endişeliyim.

resim açıklamasını buraya girin

Önerilen Yapılandırma

Aşağıda gösterildiği gibi yapılandırmamızı değiştirmenizi öneriyorum. Benim düşüncem, bu RV082 dinamik istemcilere DHCP sağlamak dışında sadece internet bağlantılı trafik görmek için sınırlayacak; ancak, müşterinin kiralama süresinin 24 saate ayarlandığı düşünüldüğünde performansın büyük bir etkisi olmasını beklemem.

Düşünceler? Endişeler? Öneriler?

Bir endişe, 2 ve 3 numaralı binalarda IP tabanlı telefonların 10 Mbps yarı çift yönlü TalkSwitch kutuları ile iletişim kurmasıdır. Bu, ağın geri kalanının performansını olumsuz etkileyecek mi?

resim açıklamasını buraya girin


7
Harika diyagram oluşturma becerilerine sahip olmak için +1
Mark Henderson

1
üst çizimin güncel olduğunu ve performanstan endişe duyduğunuzu söylüyorum, sahip olduğum soru şu şekilde çalışıyor mu? 7 kullanıcı ile wifi üzerinden Voip vpn yoğunlaştırıcı ile ilgisi olmayan bir sorun olabilir gibi görünüyor.
tony roth

@tony roth: Sistem çalışıyor, ancak çeşitli performans sorunlarımız var (büyük olasılıkla hem İSS'mizle hem de ağ mimarimizle). Soruma bazı ayrıntılar ekleyeceğim. Teşekkürler.
Matthew Rankin

Yanıtlar:


4

Wim'in daha önce belirttiği gibi, yarı dubleks önemli değil. Anahtarlar her bağlantı noktasını farklı hızlarda ve çift yönlü çalıştırabilir.

Bunu değerlendirmenin en kolay yolu, bileşenden bileşene giden yolu düşünmek ve en zayıf bağı almaktır. Bina # 2 ile genel merkez arasındaki tüm iletişim, diğer internet görevleriyle paylaşılan bir 3Mbps / 300kpbs hattı üzerinden gerçekleşir; Merkezde 10Mbps veya 100Mbps bağlantı olması fark etmez çünkü VPN bağlantısı, ara bağlantı bant genişliğini belirlemede baskın faktör olacaktır.

Diyagramınıza bakarak, teklifinizde gördüğüm malzeme değişikliği, merkezdeki iki HP 2524 anahtarı arasında 1Gbps'lik bir bağlantı getiriyor. Bir anahtarda, her biri 100Mbps ile sınırlı bir grup sunucunuz var, diğer yandan kablosuz olarak 100Mbps veya 54Mpbs ile sınırlı bir grup istemci iş istasyonunuz var. Buradaki hiçbir makine iki anahtar arasındaki veri bağlantısını tüketemeyecektir, ancak istemciler ve sunucular arasındaki birden fazla makinede yoğun trafik olduğunda, 1Gbps bağlantısını takdir edeceksiniz.


2

Teorik bir tasarım problemini çözmeye mi çalışıyorsunuz yoksa gerçek bir VoIP çağrı kalitesi probleminiz mi var?

Anahtarlardan herhangi biri, bağlantı noktası hızlarının (10/100/1000) ve duplekslerin (yarım / dolu) bir karışımını işleyebilmelidir. Bu kendi başına bir sorun olmamalı.

RV082'nin yalnızca yönlendirici olmasına izin verdim, tek bir LAN kablosu HP anahtarınıza gidiyor. Yönlendiricinin yönlendirici olmasına izin verin ve anahtar bir anahtar ...

Talkswitch'in sadece 10 HD yapması biraz saçma. Ancak yine de, sıkıştırılmamış bir ulaw / alaw VoIP çağrısı maksimum 100 kbps alır, böylece aynı anda çok sayıda çağrı sorunsuz çalıştırabilirsiniz.

Yönlendiricinizin QoS özelliklerini ve anahtarlarını biraz daha keşfedebilir / araştırmalısınız.

Bu yardımcı olabilir: http://www.hp.com/rnd/pdf_html/traffic_profiles.htm#environment2 ancak anahtarınız için doğru doküman için biraz daha avlamak zorunda kalabilirsiniz.


Bu teorik bir tasarım sorunu değildir. 3. binada VoIP çağrı kalitesi sorunları yaşıyoruz. Her ne kadar # 3 numaralı binadaki hub'ı HP ProCure 2524 anahtarıyla değiştirdiğimizde iyileşti. Daha büyük sorunumuz internet performansı. 10 Mbps yarı çift yönlü çalışan TalkSwitch'lerin genel ağ performansını olumsuz etkilediğinden endişeliyim. Ancak, temel nedeni belirlemek için sorunu henüz daraltmadım. ISS ile ilgili performans sorunları da dahil olmak üzere sorunun çok yönlü olduğuna inanıyorum.
Matthew Rankin

1

10 Mbit, yarı dubleks stok tüccarları için özel, kritik telefon sistemleri çalıştırdım ve sistemin bu yönüyle ilgili sorunlar görmedim. (IPC taretleri yalnızca 10 / yarısında çalıştırıldı.)

HQ'daki Procurves'a doğrudan bağlı bir IP telefonla arama kalitesini test ettiniz mi? Bu, anahtarlama dişlisini olası bir suçlu olarak ortadan kaldırmalıdır.

Ayrıca, RV082'lerde bant genişliği kullanımını değerlendirmek için herhangi bir izleme sisteminizin olmadığını da hissediyorum. Bu yönlendiriciler için web yönetici konsolunu kullanarak bant genişliği kullanımını kontrol etmenin kolay bir yolu yoksa, bir performans izleme sistemi uygulamayı düşünün. Başka bir hızlı Google, bu yönlendiricilerin SNMP'yi desteklediğini gösteriyor. Üzerine Cacti veya PRTG atmak için yedek bir bilgisayar bulabilirseniz, bu Internet bağlantısının doygunluk seviyesini belirlemek için uzun bir yol kat etmelidir. (Nagios'u oraya da atın, ağınız için bir kullanılabilirlik izleyiciniz var.)

Sabit veri olmadan, bina # 3'te bant genişliğinizi kısıtlayan Internet bağlantısı olduğundan şüpheleniyorum. Bu nedenle, yükseltme seçeneklerinizi ve maliyetlerinizi anlamak için sağlayıcınızla konuşmaya değer. Ancak, bir yükseltme satın almadan önce, performansı izleme yoluyla sorunu doğrulamanızı öneririm. Satın almadan önce ne kadar daha fazla satın almanız gerektiğini öğrenin.

Ayrıca, bu IP telefonları hangi codec bileşeni kullanıyor? Ben TalkSwitch aşina değilim, ama hızlı bir Google onlar G.711 veya destekleyen gösterir G.729 . 80 kbits bant genişliği kullanan G.711 kullanıyorlarsa, uzak sitedeki bu İnternet bağlantısı üzerinden en fazla 3 çağrı yapabilirsiniz. G.729 telefon bant genişliği kullanımını büyüklük sırasına göre kesecektir. Çağrı kalitesi düşecektir, bu yüzden bu değişikliği yapmadan önce yönetiminizin kurulu olduğundan emin olun. Ancak, bant genişliği kullanımının değerlendirilmesi daha uzun sürerse kısa vadede bunu yapmak faydalı olabilir.

HTH!

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.