Red de arquitectura con sistema telefónico semidúplex de 10 Mbps

Configuración actual

El siguiente diagrama muestra nuestra arquitectura de red actual. Todas las conexiones se ejecutan a 100 Mbps full duplex, con la excepción de los sistemas telefónicos TalkSwitch que funcionan a 10 Mbs half duplex (esquina superior derecha del diagrama). Las cajas TalkSwitch proporcionan 8 conexiones telefónicas analógicas y 8 basadas en IP, por lo que podemos tener un total de 16 teléfonos analógicos y 16 basados ​​en IP.

Nota: Los cuatro conmutadores administrados HP ProCurve 2524 no están configurados con VLAN separadas.

Me preocupa el impacto en el rendimiento de tener ambos conmutadores, ambas cajas TalkSwitch y el puente inalámbrico conectado a nuestro enrutador VPN RV082 en nuestra sede.

Configuración propuesta

Estoy proponiendo que cambiemos nuestra configuración como se muestra a continuación. Mi opinión es que esto limitará el RV082 a solo ver el tráfico vinculado a Internet con la excepción de proporcionar DHCP a los clientes dinámicos; sin embargo, no esperaría que eso tuviera un gran impacto en el rendimiento dado que el tiempo de arrendamiento del cliente está establecido en 24 horas.

Pensamientos? Preocupaciones? Recomendaciones?

Una de las preocupaciones es que en los edificios n. ° 2 y n. ° 3, los teléfonos basados ​​en IP se comunican con las cajas TalkSwitch a 10 Mbps de semidúplex. ¿Eso afectará negativamente el rendimiento del resto de la red?

Como Wim ya señaló, el half-duplex no importa. Los conmutadores son capaces de ejecutar cada puerto a diferentes velocidades y dúplex.

La forma más fácil de evaluarlo es pensar en la ruta de un componente a otro y tomar el enlace más débil. Toda su comunicación entre el edificio n. ° 2 y la sede se realiza a través de una línea de 3 Mbps / 300 kbps compartida con otras tareas de Internet; si tiene una conexión de 10Mbps o 100Mbps en la sede, no importará porque el enlace VPN será el factor dominante para determinar el ancho de banda de interconexión.

Mirando su diagrama, el cambio material que veo en su propuesta es la introducción de un enlace de 1 Gbps entre los dos conmutadores HP 2524 en la sede. En un conmutador tiene un montón de servidores, cada uno limitado a 100Mbps, y en el otro tiene un montón de estaciones de trabajo cliente, también limitadas a 100Mbps o 54Mpbs en redes inalámbricas. Ninguna máquina aquí será capaz de agotar el enlace de datos entre los dos conmutadores, pero con mucho tráfico en varias máquinas entre los clientes y los servidores, apreciará el enlace de 1 Gbps.

¿Está tratando de resolver un problema de diseño teórico o tiene un problema real de calidad de llamadas VoIP?

Cualquiera de los conmutadores debe ser capaz de manejar una combinación de velocidades de puerto (10/100/1000) y dúplex (medio / completo). Eso en sí mismo no debería ser un problema.

Dejaría que el RV082 sea solo el enrutador, con un solo cable LAN que vaya a su conmutador HP. Deje que el enrutador sea un enrutador, y el interruptor un interruptor ...

Es un poco tonto que el Talkswitch solo haga 10 HD. Pero aún así, una llamada VoIP ulaw / alaw sin comprimir toma un máximo de 100 kbps para que pueda ejecutar muchas llamadas simultáneas sin problema.

Podrías / deberías explorar las características de QoS de tu enrutador y cambiar un poco más.

Esto podría ayudar: http://www.hp.com/rnd/pdf_html/traffic_profiles.htm#environment2 pero es posible que tenga que buscar un poco más para encontrar el documento correcto para su conmutador.

He ejecutado sistemas de telefonía críticos y especializados para operadores bursátiles a 10 Mbit, semidúplex, y no he visto problemas con ese aspecto del sistema. (Las torretas IPC funcionaban solo a 10 / mitad).

¿Ha probado la calidad de la llamada con un teléfono IP conectado directamente a Procurves en la sede? Eso debería eliminar el cambio de marcha como un posible culpable.

También tengo la sensación de que no tiene ningún tipo de sistema de monitoreo para evaluar el uso de ancho de banda en esos RV082. Si no hay una manera fácil de verificar el uso del ancho de banda usando la consola de administración web para esos enrutadores, considere implementar un sistema de monitoreo de rendimiento. Otro rápido Google muestra que esos enrutadores admiten SNMP. Si puede encontrar una computadora de repuesto sobre la cual arrojar Cacti o PRTG, eso debería ser de gran ayuda para determinar el nivel de saturación del enlace de Internet. (Agregue Nagios allí también y tendrá un monitor de disponibilidad para su red).

Sin datos duros, sospecho que es el enlace de Internet en el Edificio # 3 lo que está restringiendo su ancho de banda. Por lo tanto, vale la pena hablar con su proveedor para comprender sus opciones y costos de actualización. Pero antes de comprar una actualización, recomendaría confirmar el problema a través de la supervisión del rendimiento. Comprenda cuánto más necesita comprar antes de comprarlo.

Además, ¿qué códec usan esos teléfonos IP? No estoy familiarizado con Talkswitch, pero un rápido Google muestra que son compatibles con G.711 o G.729 . Si usan G.711, que usa un ancho de banda de 80 kbits, podrá ejecutar como máximo 3 llamadas a través de ese enlace de Internet en el sitio remoto. G.729 reducirá el uso del ancho de banda de telefonía en un orden de magnitud. La calidad de la llamada se verá afectada, así que asegúrese de que su administración esté a bordo antes de realizar ese cambio. Pero podría ser útil hacerlo a corto plazo si la evaluación del uso del ancho de banda termina tomando más tiempo.

HTH!