aplicar QoS en un enlace de velocidad "variable" donde la negociación es realizada por los operadores NTE

En esencia, compramos una línea 80/20 del transportista que proporciona el transporte entre las instalaciones del cliente y el intercambio local donde el transportista termina en nuestro PE.

(Juniper PE) <--> [Interconexión del operador en Exchange <---> NTE en propiedad del cliente] <---> (Cisco CPE - 881,1921,1941,2921))

El circuito entre la propiedad del cliente y el gabinete de la calle local sigue siendo de cobre y, por lo tanto, a medida que aumenta el ruido / la distancia, la velocidad se reduce.

La negociación de velocidad de línea real se está llevando a cabo en los operadores NTE, no en nuestro CPE.

¿Cómo puedo asegurarme de que cuando el enlace está saturado los paquetes prioritarios no se descarten, sin saber realmente a qué se ha autenticado la velocidad de la línea? ¿Se puede hacer algo con ipsla?

qos cisco-ios-15

— DrBru
fuente

¿Estás hablando de la configuración de QoS en el CPE, para la dirección de carga?

— jwbensley

@javano bidireccional realmente, actualmente la única opción disponible para mí es dar forma al tráfico en ambos lados a un promedio tal como lo recomienda en su respuesta, estoy tratando de establecer si hay alguna otra manera de que esto se pueda hacer con mayor precisión .

— DrBru

Realmente no puede resolver esto sin hacer una suposición demasiado conservadora de qué tasa siempre se cumplirá. Investigue sobre la terminación de la conexión directamente en su Cisco CPE eliminando el NTE. Entonces la interfaz Cisco CPE sabrá la velocidad de línea.

— ytti

@ytti Gracias, actualmente sus finanzas nos llevan a usar el operador como intermediario y fttc todavía es MUY nuevo aquí.

— DrBru

@IanK sí, pero si es DSL o algo así, ¿no puede simplemente reemplazar el módem por completo y usar solo su propio CPE? Entonces podría aplicar QoS a la interfaz que conoce la tasa.

— ytti

Una posibilidad es si desea que el tráfico de QoS aguas arriba hacia la puerta de enlace del CPE sea dar forma al tráfico saliente y luego priorizar el tráfico importante dentro de ese ancho de banda de conformación.

Si se trata de una línea 80/20 y sabe que la velocidad de subida promedio es de 15 Mbps, puede configurar el tráfico saliente a 15 Mbps y priorizar la voz dentro de esos 15 Mbps. Si la velocidad de sincronización baja un par de Mbps, no habrá una gran diferencia. Si la velocidad de sincronización aumenta a 17Mbps, tendrá un par de Mbps de ancho de banda de carga.

Yo uso una configuración como el golpe en algunas líneas EFM. La velocidad de EFM puede variar debido a las condiciones de la línea, una vez instaladas, aunque parecen ser muy consistentes. Entonces, en este ejemplo, este CPE está conectado a la línea 20/20 EFM que realmente se sincroniza de manera confiable a 10/10, la carga tiene una forma de 10Mbps.

class-map match-any CM-VOICE-TRAFFIC
 match access-group 100
!
policy-map PM-PRIORITISE-VOICE
 class CM-VOICE-TRAFFIC
   set ip dscp ef
   priority 1000
 class class-default
   fair-queue
!
policy-map PM-SHAPE-10M
 class class-default
  shape average 10000000
  service-policy PM-PRIORITISE-VOICE
!
interface FastEthernet0/1
 Description WAN Interface
 bandwidth 10000
 service-policy output PM-SHAPE-10M
!
access-list 100 remark Priority IP Destinations
access-list 100 permit ip 1.2.3.0 0.0.0.255 any

Es importante que formemos aquí, no el límite de velocidad o la policía, para que el tráfico no se caiga, se "adapte" al ancho de banda disponible. Lea esta página de Cisco para obtener información adicional.

— jwbensley
fuente

No creo que esto funcione, el problema de OP es que no sabe dónde dar forma a la conexión. Si lo configura a 10Mbps, DEBE poder pasar 10Mbps para mantener el contrato 'CM-VOICE-TRAFFIC'.

— ytti