¿Qué clasificación de QoS se debe aplicar a NTP?

9

El diseño de red de referencia de solución de QoS empresarial de Cisco sugiere clasificar NTP como tráfico de administración de red y marcarlo como CS2:

Al abordar las necesidades de QoS del tráfico de administración de red, Cisco recomienda las siguientes pautas:

  • El tráfico de administración de red debe marcarse a DSCP CS2.
  • Las aplicaciones de administración de red deben protegerse explícitamente con una garantía mínima de ancho de banda.

El tráfico de administración de red es importante para realizar análisis de tendencias y capacidad y resolución de problemas. Por lo tanto, puede aprovisionar una cola separada de ancho de banda mínimo para el tráfico de administración de red, que podría incluir SNMP, NTP , Syslog, NFS y otras aplicaciones de administración .

Dado que NTP es sensible a las fluctuaciones, ¿por qué no se marca NTP como reenvío de Expedia y se trata igual que los datos de voz?

¿Hay alguna razón por la que no se debe colocar en la misma cola de baja latencia que la voz?

cisco qos best-practices ntp Stephen Craven
fuente
3
No creo que "sensible al jitter" sea una caracterización justa de NTP. Esto explica mucho, pero creo que el algoritmo y los intervalos de sondeo pueden lidiar con una cierta cantidad de jitter. Entonces eso me llevaría a pensar que no es necesario tratarlo igual que la voz. (Sin embargo, sé poco sobre QoS).
Craig Constantine
@CraigConstantine Eso es correcto. En la mayoría de los entornos, siempre que pueda obtener una cola para superar el tráfico BE, de todos modos, probablemente esté por delante del 95% de los datos.
Ryan Foley
@CraigConstantine echa un vistazo a RFP4594 Buena captura Stephen. ¿Supongo que Cisco no está alineado con el IETF en este caso? ...
Ronnie Royston
1
Cisco es una gran empresa con muchos individuos / grupos diferentes. No todos ellos siempre están de acuerdo en lo que es mejor. Personalmente, creo que la recomendación de IETF es mejor cuando se trata de "sincronización de alta precisión", pero personalmente no quisiera que NTP para mi equipo de red (que generalmente no clasificaría como alta precisión) sea "sincronización de reloj de pared" o DF como dice el RFC. La recomendación de Cisco parece estar más "en el medio del camino" y en línea con lo que yo esperaría para satisfacer las necesidades generales de NTP para equipos de red.
YLearn
1
@StevenCraven, para que esta sea una pregunta que debe responderse, debemos comprender qué tipo de requisitos de precisión tiene para NTP y cómo se está utilizando.
Mike Pennington

Respuestas:

2

Respuesta editada: NTP debe colocarse en la clase EF (igual que los paquetes de voz en tiempo real) de acuerdo con las Pautas de configuración RFC 4594 de IETF para las clases de servicio DiffServ .

5.2. Mapeo para NTP

De las pruebas que se realizaron, las indicaciones indican que la distribución precisa del tiempo requiere un transporte de variación de retardo de paquete (jitter) muy bajo. Por lo tanto, sugerimos que se usen las siguientes pautas para el Protocolo de tiempo de red (NTP):

o Cuando se utiliza NTP para proporcionar temporización de alta precisión dentro de la red de un administrador (operador) o para usuarios / clientes finales, se debe usar la clase de servicio de telefonía , y los paquetes NTP deben marcarse con el valor EF DSCP.

o Para aplicaciones que requieren precisión de temporización de "reloj de pared", se debe usar la clase de servicio estándar y los paquetes deben marcarse con DSCP de DF.

Ronnie Royston
fuente
corregido arriba
Ronnie Royston
3

NTP no es particularmente sensible a la fluctuación de fase, ya que utiliza originatey transmitmarcas de tiempo para realizar un seguimiento de demora. Ntp.org explica en detalle cómo se mantiene el retraso en el control , pero aquí hay un fragmento:

La sincronización de un cliente con un servidor de red consta de varios intercambios de paquetes donde cada intercambio es un par de solicitud y respuesta. Al enviar una solicitud, el cliente almacena su propio tiempo (marca de tiempo de origen) en el paquete que se envía. Cuando un servidor recibe dicho paquete, a su vez almacenará su propio tiempo (recibirá la marca de tiempo) en el paquete, y el paquete se devolverá después de colocar una marca de tiempo de transmisión en el paquete. Al recibir la respuesta, el receptor volverá a registrar su propio tiempo de recepción para estimar el tiempo de viaje del paquete. El tiempo de viaje (demora) se estima en la mitad de "la demora total menos el tiempo de procesamiento remoto", suponiendo demoras simétricas.

La razón por la cual esto no está en la misma categoría que el control de red es porque no es directamente responsable de la operación de enrutamiento / reenvío de paquetes. Todas las cosas en la categoría de administración de red no son componentes críticos del sistema de red en su conjunto. Si perdió algún paquete relacionado con SNMP, syslog o NTP, es probable que ni siquiera lo note.

SNMP simplemente retransmitiría esa información ya que está basada en TCP. Incluso si la conexión se cortara por completo, no ocurriría nada catastrófico; es posible que un agente snmp no responda y luego intente nuevamente. Si perdió el tráfico de syslog (UDP), simplemente perdería un poco de información de registro, que probablemente todavía está contenida dentro del búfer o en un archivo de registro en el dispositivo. Dado que NTP calcula la demora en función de los paquetes anteriores, al tiempo que representa el error de desplazamiento máximo, realmente no tiene ningún problema. En el peor de los casos, su tiempo se desplaza unos pocos picosegundos ...

Si perdió un paquete relacionado con el enrutamiento, incluso por un segundo, puede estar enfrentando la caída de todo el sistema; haciendo que cualquier otra marca no tenga valor. En ese momento, el NTP simplemente no se sincronizaría por completo y dependería de su ticker local para mantener el tiempo.

Ryan Foley
fuente