Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Protocolo de tiempo de precisión

RESUMEN El protocolo de tiempo de precisión (PTP) es un protocolo basado en el tiempo, diseñado para distribuir tiempo y frecuencia precisos a través de redes Ethernet conmutadas por paquetes.

Descripción general de PTP

PTP, también conocido como IEEE 1588v2, es una tecnología basada en paquetes que permite al operador ofrecer servicios de sincronización en redes de retorno móvil basadas en paquetes. El estándar de sincronización de reloj IEEE 1588 PTP (versión 2) es un protocolo de alta precisión para la sincronización de tiempo que sincroniza relojes en un sistema distribuido. La sincronización de tiempo se logra mediante paquetes que se transmiten y reciben en una sesión entre un reloj principal y un reloj de cliente.

Los relojes del sistema se pueden clasificar según la función del nodo en la red. Se clasifican ampliamente en relojes ordinarios y relojes de límite. El reloj principal y el reloj del cliente se conocen como relojes ordinarios. El reloj de límite puede funcionar como un reloj principal o como un reloj de cliente. La siguiente lista explica estos relojes en detalle:

  • Reloj principal: el reloj principal transmite los mensajes a los clientes PTP (también denominado nodo de cliente o nodo de límite). Esto permite a los clientes establecer su distancia de tiempo relativa y el desplazamiento desde el reloj principal (que es el punto de referencia) para la sincronización de fase. El mecanismo de entrega a los clientes es paquetes de unidifusión o multidifusión a través de Ethernet o UDP.

  • Reloj de miembro: se encuentra en el cliente PTP (también llamado nodo de cliente), el reloj de cliente realiza operaciones de recuperación de reloj y tiempo en función de las marcas de hora recibidas y solicitadas del reloj principal.

  • Reloj de límite: el reloj de límite funciona como una combinación de los relojes principal y cliente. El punto de conexión del reloj de límite actúa como reloj de cliente al reloj principal y también actúa como el principal para todos los esclavos que informan al punto de conexión de límite.

Para obtener más información acerca de la configuración de PTP, consulte Configurar protocolo de tiempo de precisión.

La tabla 1 resume la primera versión de Junos OS que admite PTP en varios dispositivos de Juniper Networks:

Tabla 1: Soporte del protocolo de tiempo de precisión

Dispositivos de Juniper Networks

Versión de Junos OS

Plataformas de enrutamiento universal MX80 con número de modelo MX80-P

12.2

MX-MPC2E-3D-P (MPC2E P) en enrutadores MX240, MX480 y MX960

12.2

MX-MPC2E-3D-P (MPC2E P) en enrutadores MX2010 y MX2020

12.3

MX-MPC2E- 3D-NG (MPC2E NG)

15.1R2

MPC4E-3D-32XGE-SFPP en MX240, MX480, MX960, MX2010, MX2020

15.1R1

MPC4E-3D-2CGE-8XGE en MX240, MX480, MX960, MX2010, MX2020

15.1R1

MPC3E-3D-NG-Q en MX240, MX480, MX960, MX2010, MX2020

15.1R2

MPC3E-3D-NG en MX240, MX480, MX960, MX2010, MX2020

15.1R2

Los siguientes MPC mejorados admiten PTP (1588v2):

  • MPC5E-40G10G en enrutadores MX240, MX480, MX960, MX2010 y MX2020

  • MPC5EQ-40G10G en enrutadores MX240, MX480, MX960, MX2010 y MX2020

  • MPC5E-100G10G en enrutadores MX240, MX480, MX960, MX2010 y MX2020

  • MPC5EQ-100G10G en enrutadores MX240, MX480, MX960, MX2010 y MX2020

  • MX2K-MPC6E en enrutadores MX2010 y MX2020

14.2R2

Tarjetas de interfaz modular (MIC) Ethernet en enrutadores MX240, MX480 y MX960

12.2

Tarjetas de interfaz modular (MIC) Ethernet en enrutadores MX2010 y MX2020

12.3

En los enrutadores MX240, MX480, MX960, MX2010 y MX2020, los siguientes MPC mejorados (MPCA) admiten PTP (1588v2) solo con licencia expresa:

  • MPC1E (MX-MPC1E-3D)

  • MPC1E Q (MX-MPC1E-3D-Q)

  • MPC2E (MX-MPC2E-3D)

  • MPC2E Q (MX-MPC2E-3D-Q)

  • EQ MPC2E (MX-MPC2E-3D-EQ)

Para obtener más información acerca de cómo obtener una licencia, póngase en contacto con JTAC.

12.3

Enrutadores universales para redes metropolitanas serie ACX

12.2

MPC6E, MPC7E, MPC8E, MPC9E, MPC2E NG y MPC3E NG en MX2008.

17.2

PIC de puerto fijo (6xQSFPP) y MIC modular (JNP-MIC1) en enrutadores MX10003

17.3

PIC de puerto fijo (4xQSFP28 y 8xSFPP) en enrutadores MX204

17.4

MPC7E-10G y MPC7E-MRATE en MX240, MX480, MX960, MX2010, MX2020

17.4

MPC8E y MPC9E en MX2010, MX2020

17.4

Nota:
  • Actualmente, no se admite la actualización unificada de software en servicio (ISSU unificado) cuando la sincronización de reloj está configurada para PTP y Ethernet síncrono en las MIC y MPCA mejorados en enrutadores MX240, MX480, MX960, MX2010 y MX2020.

  • Para cambiar entre los modos PTP y Ethernet sincrónica, primero debe desactivar la configuración para el modo actual y, luego, confirmar la configuración. Espere un breve período de 30 segundos, configure el nuevo modo y sus parámetros relacionados y, a continuación, confirme la configuración.

  • Es posible que la configuración PTP no funcione correctamente cuando el enrutador MX10008 con la tarjeta de línea JNP10K-LC2101 y el hipermodo habilitado. El hipermodo se puede habilitar de forma predeterminada cuando el enrutador MX10008 tiene la tarjeta de estructura del conmutador 2 (SFB2), o mediante el comando set forwarding-options hyper mode. Por lo tanto, tales interfaces PTP (esclavo, maestro, estado) no son compatibles.

Grupo de agregación de vínculos de PTP

Junos admite PTP sobre LAG según la recomendación del ITU-T-G.8275.1. Para cada vínculo de Ethernet agregado configurado como PTP principal o cliente, puede especificar un vínculo miembro del paquete de Ethernet agregado como principal y otro como secundario. El PTP cambia al miembro secundario del paquete de Ethernet agregado cuando el vínculo de Ethernet agregado principal está inactivo. Para proporcionar redundancia a nivel de vínculo y A nivel de FPC, las interfaces principal y secundaria del paquete de Ethernet agregado deben configurarse en tarjetas de línea separadas. Si tanto la principal como la secundaria están configuradas en la misma tarjeta de línea, solo proporcionaría redundancia a nivel de vínculo.

Las secuencias principales de PTP se crean en la FPC en la que está presente la interfaz principal. Los paquetes de anuncio y sincronización se transmiten en este vínculo activo de Ethernet agregado PTP. La tarjeta de línea del cliente PTP que contiene este vínculo De Ethernet agregado PTP activo recibirá paquetes anunciados y sincronizados desde el principal remoto.

Esta tabla resume la primera versión de Junos OS que admite PTP sobre LAG con encapsulación PTPoE en varios dispositivos de Juniper Networks:

Tabla 2: PTP sobre LAG con soporte de encapsulación PTPoE

Dispositivos de red de Juniper

PTP a través de IPv4

PTP a través de Ethernet

MPC2E NG

17.2R1

MPC3E NG

17.2R1

MPC5E

17.2R1

18.2R1

MPC6E

17.2R1

18.2R1

MPC7E-10G

18.1R1

18.3R1

MPC7E-MRATE

18.1R1

18.3R1

MPC8E

18.1R1

18.3R1

MPC9E

18.1R1

18.3R1

MX10008 22.4R1 22.4R1
MX10004 con MX10K-LC480 23.1R1 23.1R1
PTX10001-36MR 23.1R1 23.1R1
Nota: Es posible que el PTP no funcione correctamente si una interfaz ethernet agregada (AE) está configurada en el enrutador MX10008 con tarjeta de línea JNP10K-LC2101. Si los vínculos primarios o secundarios de la AE no admiten PTP con hipermodeo, el AE completo se marca como no compatible.

Descripción general del seguimiento de PTP

El protocolo de tiempo de precisión (PTP), también conocido como IEEE 1588v2, funciona según el principio de sincronización de fase y frecuencia: sincroniza tanto la frecuencia como la fase, incluida la hora del día. La sincronización de fase se logra ajustando la fase del reloj del cliente (oscilador interno del enrutador) desinteresadamente (recibiendo señales de reloj del reloj principal en períodos de tiempo irregulares) o ajustando el bucle bloqueado de fase del reloj interno del cliente a intervalos regulares. La precisión de la sincronización del reloj depende de factores como la variación del retraso del paquete, la calidad del oscilador utilizado, la asimetría de red, etc.

Puede implementar un mecanismo de seguimiento de ruta para detectar bucles PTP que circulan interminablemente dentro de un anillo PTP de relojes de límite a través de una red IPv4. La implementación de la topología de anillo PTP utiliza el mecanismo de seguimiento de ruta 1588v2 para evitar los bucles PTP y proporcionar convergencia PTP en caso de que se produzca alguna falla en un solo punto.

En las siguientes secciones se explica el mecanismo de seguimiento de ruta y cómo se implementa en una topología de anillo PTP de reloj de múltiples referencias a través de una red IPv4. Las secciones también explican el estado estacionario y el manejo de errores en una topología de anillo PTP:

Topología de anillo PTP

Una topología de anillo PTP es una topología de anillo que consta de uno o más relojes de referencia y varios relojes de límite.

Considere una topología de anillo simple de los relojes de límite (BC1 a BC5) impulsada por un reloj de referencia PTP principal y un reloj de referencia PTP de respaldo (GM-A y GM-B, respectivamente), como se ilustra en la figura 1. Supongamos que GM-A es superior a GM-B, es decir, el nivel de calidad del reloj de GM-A es mayor que el del reloj de GM-B.

Figura 1: Topología de anillo PTP de reloj de referencia múltiple Multiple-reference Clock PTP Ring Topology

Cada reloj de límite en el anillo PTP está configurado como cliente y principal a su vecino inmediato para proporcionar un cambio de reloj de referencia PTP sin problemas en caso de falla del reloj de referencia o de límite. Por ejemplo, en la Figura 1 , BC2 es tanto principal como cliente para BC1 y BC3, BC3 es tanto principal como cliente para BC2 y BC4, y así sucesivamente.

Mecanismo de seguimiento de ruta para manejar fallas de PTP

Durante el proceso de sincronización en una topología de anillo PTP, ciertos mensajes de anuncio (mensajes de información de temporización que se envían desde el principal al cliente) pueden formarse en un bucle infinito (también llamado bucle PTP) en una pista de reloj de límite de red. Estos bucles PTP crean problemas, como un reloj de límite que potencialmente sincroniza su reloj local con su propia información de temporización, lo que compromete la calidad del reloj recuperado. El mecanismo de seguimiento de ruta se utiliza para detectar dichos bucles.

Un seguimiento de ruta es la ruta que un mensaje de anuncio PTP toma a través del rastro de la red de los relojes de límite y se rastrea a través del rastreo de ruta TLV en el mensaje de anuncio. Una TLV de seguimiento de ruta (tipo, longitud y valor) es un conjunto de octetos en un mensaje de anuncio que incluye el tipo de TLV, el campo de longitud y la secuencia de ruta. La secuencia de seguimiento de ruta contiene el ID de reloj de cada reloj de límite que un mensaje de anuncio atraviesa a través del anillo PTP.

Uno de los usos principales del mecanismo de rastreo de ruta es detectar los llamados mensajes anunciadores no autorizados que circulan interminablemente en bucles en el anillo PTP de los relojes de límite. Un reloj de límite detecta un bucle PTP cuando encuentra su propio ID de reloj en el seguimiento de ruta del mensaje de anuncio recibido. Cuando se detecta un bucle de este tipo, el enrutador descarta el mensaje de anuncio recibido.

Para ver la ruta del seguimiento del mensaje de anuncio o del seguimiento de ruta, utilice el comando del show ptp path-trace detail modo operativo. Para obtener más información, consulte mostrar detalles de seguimiento de ruta ptp.

Nota:
  • Durante el GRES, el rastreo de la ruta y la mejor información del algoritmo de reloj principal se empujan al kernel. Por lo tanto, esta información también está disponible en el motor de enrutamiento de respaldo.

  • Cuando el número de relojes de límite en una topología supera los 20, se pierde la TLV de seguimiento de ruta.

  • Actualmente, la topología de anillo PTP solo se admite para redes PTP a través de redes IPv4.

Estado estable

Se considera que el anillo PTP está en estado estable o funciona normalmente cuando un enrutador, por ejemplo, BC1, está bloqueado, es decir, está conectado y sincronizado, a un reloj de referencia que tiene un valor de nivel de calidad más alto que el nivel de calidad de otros relojes de referencia en la red, y todos los demás enrutadores en el anillo PTP están bloqueados al reloj de referencia a través de este enrutador BC1. Por ejemplo, en la Figura 1, durante el estado estacionario, BC1 se bloquea a GM-A, BC2 y BC5 se bloquean a BC1, BC3 se bloquea a BC2 y BC4 se bloquea a BC5. Cuando se implementa el mecanismo de seguimiento de ruta en esta topología de anillo, se asigna un ID de reloj a cada reloj de límite que, a su vez, se incluye en el seguimiento de ruta TLV dentro del mensaje de anuncio. Por lo tanto, el seguimiento de ruta TLV en el mensaje de anuncio que se origina en BC1 tiene su propio ID de reloj: CID1. Del mismo modo, el mensaje de anuncio de BC2 tiene su propio ID de reloj (CID2) y el ID de reloj de BC1 (CID1), entre otros.

Como el enrutador BC2 es el principal para BC1, BC1 recibe constantemente los mensajes de anuncio de BC2. Los mensajes de anuncio de BC2 recibidos en BC1 contienen el ID de reloj de BC1 (CID1) junto con el ID de reloj de BC2(CID2). Dado que BC1 recibe su propio ID de reloj (CID1) en el mensaje de anuncio, BC1 deja caer los mensajes de anuncio de BC2. De manera similar, BC2 deja caer los mensajes de anuncio de BC3, ya que los mensajes contienen el ID de reloj de BC2 (CID2) junto con otros ID de reloj (CID1 y CID3). Tenga en cuenta que este comportamiento es intencional y por diseño, como se explica en el manejo de fallas.

Manejo de fallas

Considere una situación en la que el enrutador BC1 se bloquea en el anillo PTP que se ilustra en la figura 1. Esta falla se maneja de la siguiente manera:

  1. El enrutador BC2 deja de recibir mensajes de anuncio de BC1.

  2. Los mensajes de anuncio que ahora recibe BC2 son solo los enviados por BC3. BC2 elimina estos mensajes de anuncio porque contienen el ID de reloj de BC2: CID2.

  3. Dado que BC2 no recibe ningún mensaje de anuncio válido, entra en modo de espera y reduce el valor de sus parámetros de anuncio, como la clase de reloj, lo que da como resultado que BC2 anuncie mensajes que lleven una clase de reloj inferior.

  4. Cuando BC3 recibe estos mensajes de anuncio con clase de reloj inferior de BC2, a su vez anuncia esta clase de reloj inferior a todos los enrutadores descendentes.

  5. Cuando BC5 finalmente recibe este mensaje de anuncio con el valor de nivel de calidad inferior de BC4, el mejor algoritmo de reloj principal que se ejecuta en el enrutador BC5 cambia BC5 a GM-B automáticamente y el enrutador BC5 envía mensajes de anuncio correspondientes a los parámetros establecidos por GM-B.

  6. Cuando BC4 recibe este mensaje de anuncio (con información superior de clase de reloj en comparación con la que lleva el mensaje de anuncio de BC3), el enrutador BC4 cambia a BC5. De manera similar, BC3 se bloquea a BC4 y luego BC2 se bloquea a BC3. En otras palabras, la topología de anillo que se muestra en la Figura 1 converge en una jerarquía en el sentido de las agujas del reloj de límite. Todo este proceso tarda unas pocas decenas de segundos.

Tenga en cuenta que cada mejor conmutación de algoritmo de reloj principal PTP en cada reloj de límite es perfecta y, por lo tanto, garantiza que el rendimiento del anillo PTP no se degrade. Sin embargo, cuando hay varias fallas simultáneas en la topología de anillo (por ejemplo, fallas de vínculo simultáneos entre GM-A y BC1 y entre BC4 y BC5), el error de intervalo de tiempo máximo absoluto (MTIE) a corto plazo puede subir a 650ns, por ejemplo, entre enrutadores BC2 a BC4. Tenga en cuenta que este tipo de errores múltiples en una topología de anillo es poco común.

MTIE es un error de variación de fase máxima que se mide durante un período de tiempo, en el que el error se calcula entre la variación de fase de una señal con la señal perfecta.

Topología de anillo PTP sin mecanismo de rastreo de ruta

Cuando no se implementa el mecanismo de seguimiento de ruta PTP, el enrutador BC2 no puede detectar mensajes de anuncio de BC3 que en realidad son mensajes de anuncio de bucle de BC2. Esto, a su vez, da como resultado que BC2 intente bloquearse a BC3 (mientras que BC3 ya está bloqueado a BC2) y se crea un bloqueo de PTP. Debido al bloqueo del PTP, hay una desviación de reloj significativa durante un período de tiempo tanto en BC2 como en BC3 y potencialmente en todos los relojes de límite que se pueden rastrear a BC3.

Tenga en cuenta que cuando aparece el enrutador bc1, elige GM-A como su principal, y envía mensajes de anuncio que contienen información superior de clase de reloj en comparación con los transportados por los mensajes de anuncio enviados por GM-B. El mejor algoritmo de reloj principal del enrutador BC2 determina que los mensajes de anuncio de BC1 contienen información de clase de reloj superior en comparación con el BC3, lo que da como resultado que BC2 vuelva a cambiar a BC1. De manera similar, BC3 vuelve a cambiar a BC2. De esta manera, la topología de anillo se restaura a la topología anterior al bloqueo.

Redundancia de tarjeta de línea para PTP

La redundancia de tarjeta de línea es uno de los escenarios de redundancia PTP posibles en una solución de retorno móvil. Se configuran varias secuencias de cliente en las tarjetas de línea y, si la tarjeta de línea de cliente actualmente activa se bloquea o todas las transmisiones de esa tarjeta de línea pierden sus paquetes de tiempo, otra tarjeta de línea de cliente puede tomar el control si está preparada para hacerlo.

Cuando configure la redundancia de tarjeta de línea, se crean flujos de cliente en tarjetas de línea adecuadas. En este momento, todas las tarjetas de línea están en modo DPLL. Todos los flujos de clientes están preparados para recibir y procesar mensajes de anuncio.

Cada tarjeta de línea ejecuta el algoritmo BMCA e identifica la mejor primaria y la secuencia que sirve a la mejor primaria. La tarjeta de línea envía la mejor información principal al RE. Después de recibir la mejor información principal de tarjetas de línea individuales, el RE selecciona al mejor principal para servir al nodo de BC. Esta información se propaga a todas las tarjetas de línea. Una vez que el RE seleccione el mejor principal, se ejecutará la máquina de estado PTP regular.

Si el algoritmo de BMCA da como resultado un cambio de flujo y la nueva transmisión cae en una tarjeta de línea diferente, se activará una conmutación sin impactos. La nueva tarjeta de cliente puede configurarse en modo PTP o híbrido puro. La tarjeta de cliente antigua puede estar en el modo de cliente PTP puro o cliente híbrido. Las tarjetas de línea deben pasar por los siguientes pasos:

  • Una transición de tarjeta de línea de cliente debe ocurrir a través del estado de espera en la tarjeta de línea principal.

  • FSM debe convertir la tarjeta de línea de cliente antigua al modo principal PTP puro.

  • En la nueva tarjeta de cliente, la FSM debe activarse según el PTP puro o el modo de operación híbrido. Todas estas transiciones deben ser sin problemas.

Nota:
  • La redundancia de tarjeta de línea limitada se admite en tarjetas de línea NG-MPCE2, 3, MPCE5, MPCE6, MPCE7, MPCE8, MPCE9 y MPCE10.
  • El cambio de BMCA de un puerto en una tarjeta de línea a otra no tiene problemas.
  • La configuración de puerto de estado o esclavo en más de tarjetas de dos líneas no se admite en las plataformas de enrutamiento universal MX960, MX480, MX240, MX2020, MX2010, MX10003 y MX2008. Esta limitación no es aplicable a MX10K (plataformas MX10008, MX10016 y MX10004.

Defectos de tiempo y administración de eventos en plataformas de enrutamiento

Junos OS para enrutadores metro universales ACX admite capacidades de administración de defectos y eventos para funciones de temporización. Los defectos y eventos se notifican en forma de capturas SNMP y estas capturas SNMP se registran en el archivo de registro del sistema (var/log/snmpd). Para cada una de las capturas SNMP (defectos de tiempo y eventos de temporización) que se generan, se registra un mensaje en el archivo clksyncd (var/log/clksyncd).

En la tabla 1, se muestra la lista de notificaciones de captura SNMP para los defectos de tiempo y los eventos admitidos en los enrutadores universales para redes metropolitanas de ACX.

Tabla 3: Notificaciones de captura SNMP para eventos y defectos de tiempo

Trampa SNMP

Tipo de notificación

Descripción

jnxTimingFaultLOS

Defectos

Indica pérdida de señal

jnxTimingFaultEFD

Defectos

Indica desviación de frecuencia excedida

jnxTimingFaultLOESMC

Defectos

Indica pérdida del canal de mensajes de sincronización Ethernet (ESMC)

jnxTimingFaultQLFailed

Defectos

Indica fallas en el nivel de calidad

jnxTimingFaultLTI

Defectos

Indica pérdida de información de tiempo

jnxTimingFaultPriSrcFailed

Defectos

Indica el error de la fuente principal

jnxTimingFaultSecSrcFailed

Defectos

Indica la falla de origen secundario

jnxTimingFaultPtpUniNegRateReject

Defectos

Cuando actúa como principal, esta captura SNMP indica un error o rechaza a los clientes para mensajes de señalización. Cuando se actúa como cliente, esta captura SNMP indica un error o el cliente deja de recibir mensajes de señalización

jnxTimingEventPriSrcRecovered

Eventos

Indica la recuperación del origen principal

jnxTimingEventSecSrcRecovered

Eventos

Indica la recuperación de un origen secundario

jnxTimingEventPriRefChanged

Eventos

Indica un cambio en la referencia principal, como un cambio en la interfaz lógica o un cambio de SyncE a BITS/interfaz externa)

jnxTimingEventSecRefChanged

Eventos

Indica un cambio en la referencia secundaria, como un cambio en la interfaz lógica

jnxTimingEventQLChanged

Eventos

Indica un cambio en el nivel de calidad

jnxTimingEventDpllStatus

Eventos

Indica el estado de DPLL (SyncE, BITS, híbrido)

jnxTimingEventPtpServoStatus

Eventos

Indica los siguientes estados del servo PTP:

  • INICIALIZAR

  • ADQUISICIÓN (Se elige la primaria y el servo comienza a adquirir bloqueo)

  • ALINEADOS POR FASE (bloqueados en el sistema principal)

  • FREERUN (sin fuente PTP disponible)

  • HOLDOVER (Miembro bloqueado en PTP durante más de 12 horas y luego pierde todas las fuentes PTP)

jnxTimingEventPtpClockClassCambio

Eventos

Indica un cambio en la clase de reloj PTP

jnxTimingEventPtpClockAccuracyCambio

Eventos

Indica un cambio en la precisión del PTP

jnxTimingEventPtpGMCambio

Eventos

Indica un cambio en el reloj de referencia PTP

jnxTimingEventHybridStatus

Eventos

Indica los siguientes estados híbridos:

  • INICIALIZAR

  • ADQUISICIÓN (Se elige la primaria y el servo comienza a adquirir bloqueo)

  • FRECUENCIA BLOQUEADA (Frecuencia bloqueada pero fase de adquisición)

  • ALINEACIÓN DE FASE (Bloqueo de frecuencia y fase)

Para configurar y generar defectos de tiempo y notificaciones de captura de eventos, incluya la timing-events instrucción en el nivel de jerarquía [edit snmp trap-group trap-group-name categories] como se muestra a continuación:

La siguiente es una configuración de ejemplo para la temporización SNMP en enrutadores serie ACX:

MIB SNMP para temporización en plataformas de enrutamiento

Junos OS para enrutadores metro universales ACX admite capacidades de administración de get, get-next y walk de SNMP para funciones de temporización. Estas capacidades se habilitan a través de los objetos de temporización PTP MIB, MIB SyncE y GPS MIB.

Nota:

Los objetos de temporización PTP MIB y SYNCE MIB se agrupan en el jnxTimingNotfObjects objeto MIB SNMP.

En la tabla 1, se muestra la lista de objetos MIB SNMP compatibles con la administración de snmp get, get-next y walk en los enrutadores universales para redes metropolitanas de ACX.

Tabla 4: Objetos MIB SNMP para administración de get, get-next y walk

SNMP MIB

Objeto

Descripción

PTP MIB

jnxPtpServoState

Indica los siguientes estados del servo PTP:

  • INICIALIZAR

  • ADQUIRIR

  • ALINEACIÓN DE FASE

  • DESACOSTE

  • REMANENTE

  • FRECUENCIA BLOQUEADA

jnxPtpServoStateStr

Indica la cadena de estado servo PTP:

  • INICIALIZAR

  • ADQUISICIÓN (Se elige la primaria y el servo comienza a adquirir bloqueo)

  • ALINEADOS POR FASE (bloqueados en el sistema principal)

  • FREERUN (sin fuente PTP disponible)

  • HOLDOVER (Miembro bloqueado en PTP durante más de 12 horas y luego pierde todas las fuentes PTP)

jnxPtpClass

Indica la clase del reloj de referencia PTP.

jnxPtpGmId

Indica el identificador de reloj de referencia PTP.

SyncE MIB

jnxClksyncQualityCode

Indica el nivel de calidad SSM/ESMC del origen bloqueado en formato decimal.

jnxClksyncQualityCodeStr

Indica el nivel de calidad SSM/ESMC del origen bloqueado en formato de cadena

jnxClksyncIfIndex

Indica el índice de interfaz del origen bloqueado en formato decimal.

jnxClksyncIntfName

Indica el nombre de interfaz del origen bloqueado en formato de cadena.

GPS MIB

jnxGpsRecvStatus

Muestra el estado del receptor GPS.

Nota:
  • La administración de get and walk snmp solo se admite para objetos escalares.

  • Para los objetos SyncE, los objetos jnxClksyncQualityCode, jnxClksyncQualityCodeStr, jnxClksyncIfIndex y jnxClksyncIntfName solo se muestran para el origen bloqueado.

Puede usar los show chassis synchronization extensivecomandos , show ptp lock-status detail, show snmp mib get <MIB-timing-objects>y show snmp mib walk jnxTimingNotfObjects mostrar para fines de supervisión y solución de problemas.

A continuación se muestra el ejemplo de los resultados de los comandos para referencia:

muestra la sincronización extensa del chasis

muestra la sincronización extensa del chasis

muestra detalles del estado de bloqueo ptp

mostrar snmp mib obtener <MIB-timing-objects>

mostrar snmp mib walk jnxTimingNotfObjects

Soporte de temporización parcial asistida en plataformas de enrutamiento

El soporte de temporización parcial asistida (APTS), que es un sistema global de navegación por satélite (GNSS) respaldado por el protocolo de tiempo de precisión (PTP), ofrece temporización y sincronización precisas en las redes de retorno móviles.

Nota:

La función APTS solo se admite en junos OS versión 12.3X54–D25 para el enrutador ACX500.

En el enrutador ACX500, la función APTS le ayuda a configurar los puertos de cliente PTP en un reloj de referencia GNSS que sirve como PTP principal.

APTS usa GNSS como referencia de tiempo principal en ubicaciones de sitio celular o en un punto de agregación cercano a los sitios de celdas. APTS usa la distribución de temporización basada en la red para asistir y mantener el tiempo durante los períodos de espera cuando el GNSS no está disponible.

Para admitir esta función, necesita un nodo APTS con origen GNSS configurado en el nivel de jerarquía [edit chassis synchronization] y un reloj de límite PTP configurado en el nivel de jerarquía [edit protocols ptp] como se muestra a continuación:

Configuración de GNSS

Configuración de PTPoE

Configuración de PTPoIP

La prioridad del origen del reloj sería primero GNSS y luego PTP.

Puede usar los show ptp lock-status detailcomandos , show chassis synchronization extensivey show chassis synchronization gnss extensive mostrar para supervisar y solucionar problemas de las configuraciones.

Sistema de posicionamiento global (GPS) en plataformas de enrutamiento

El sistema de posicionamiento global (GPS) es un sistema de ayuda a la navegación que utiliza señales de satélites para calcular la posición real de un receptor compatible con GPS. Estas señales no solo se utilizan para determinar la posición del receptor en la Tierra, sino también como una base de tiempo muy precisa. Hay receptores GPS con salida de frecuencia de reloj de 10 MHz sincronizado con un satélite GPS. El enrutador de la serie ACX tiene un conector de subminiatura versión B (SMB) que puede tomar una entrada de onda sinusoidal de 10 MHz desde un receptor GPS. Para configurar este reloj de 10 MHz desde un receptor GPS como fuente de reloj candidata para la sincronización del chasis, incluya la gps instrucción y las opciones en el nivel de jerarquía de [edit chassis sync source].

Nota:

Los enrutadores ACX500 no requieren un receptor GPS externo, ya que el receptor GPS está integrado en el sistema.

Sistema global de navegación por satélite (GNSS) integrado en plataformas de enrutamiento

El sistema global de navegación por satélite (GNSS) es un sistema de ayuda a la navegación que utiliza señales de satélites para calcular la posición real de un receptor compatible con GPS. Estas señales no solo se utilizan para determinar la posición del receptor en la Tierra, sino también como una base de tiempo muy precisa.

El enrutador de la serie ACX500 tiene el receptor GNSS integrado en el sistema. Esto elimina la necesidad de tener un receptor GPS externo. Sin embargo, necesitará una antena GPS. Los enrutadores de la serie ACX500 admiten entrada GNSS a través del conector de subminiatura versión A (SMA). Puede configurar el puerto GNSS y sus parámetros asociados en el nivel jerárquico de [editar sincronización de chasis].

Puede configurar el puerto GNSS incluyendo la constellation gps] instrucción CLI en el nivel de jerarquía [edit chassis synchronization port gnss]. Si no especifica una constellation opción, la opción de constelación gps se considera de forma predeterminada.

El siguiente es el nivel de jerarquía [edit chassis synchronization port gnss]:

Nota:
  • El rango para cable-length-compensation es de 0 to 50000000 nanosegundos.

  • El receptor GNSS integrado en los enrutadores de la serie ACX500 no admite entrada y salida de frecuencia de 10 MHz.

  • PTP no se admite en puertos 1G en todas las plataformas. Consulte funciones de PTP y plataformas compatibles para obtener información sobre las plataformas PTP y las funciones de PTP compatibles.

Los enrutadores de la serie ACX500 admiten la funcionalidad de reloj de referencia con el receptor GNSS integrado.

Utilice el show chassis synchronization gnss comando para comprobar el estado del receptor GNSS. Para obtener más información, consulte Mostrar sincronización del chasis.