EN ESTA PÁGINA
Temporización de defectos y gestión de eventos en plataformas de enrutamiento
Soporte de temporización parcial asistida en plataformas de enrutamiento
Sistema de posicionamiento global (GPS) en plataformas de enrutamiento
Sistema mundial integrado de navegación por satélite (GNSS) en plataformas de enrutamiento
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 los relojes en un sistema distribuido. La sincronización de tiempo se logra a través de paquetes que se transmiten y reciben en una sesión entre un reloj primario y un reloj cliente.
Los relojes del sistema se pueden clasificar en función de la función del nodo en la red. Se clasifican ampliamente en relojes ordinarios y relojes límite. El reloj primario y el reloj cliente se conocen como relojes ordinarios. El reloj de límite puede funcionar como reloj principal o como reloj cliente. La siguiente lista explica estos relojes en detalle:
-
Reloj primario: el reloj principal transmite los mensajes a los clientes PTP (también denominados nodo cliente o nodo límite). Esto permite a los clientes establecer su distancia de tiempo relativa y el desplazamiento del reloj primario (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 miembro: ubicado en el cliente PTP (también denominado nodo cliente), el reloj del cliente realiza operaciones de recuperación de reloj y hora en función de las marcas de tiempo 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 extremo del reloj de límite actúa como un reloj de cliente para el 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 el protocolo de tiempo de precisión.
Consulte la página Explorador de características para confirmar la compatibilidad de la plataforma y la versión para características específicas.
-
Actualmente, la actualización unificada de software en servicio (ISSU unificada) no se admite cuando la sincronización del reloj está configurada para PTP y Ethernet sincrónica en las MIC y MPCE mejorados en enrutadores MX240, MX480, MX960, MX2010 y MX2020.
-
Para cambiar entre los modos PTP y Ethernet síncrona, primero debe desactivar la configuración para el modo actual y, a continuación, 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 de PTP no funcione correctamente cuando MX10008 enrutador con tarjeta de línea JNP10K-LC2101 e hipermodo habilitado. El hipermodo se puede habilitar de forma predeterminada cuando MX10008 enrutador tiene la placa de estructura de conmutación 2 (SFB2) o mediante el comando
set forwarding-options hyper mode. Por lo tanto, tales interfaces PTP (esclavo, maestro, estado) no son compatibles.
PTP a través de Link Aggregation Group
Junos admite PTP sobre LAG según la recomendación de ITU-T-G.8275.1. Para cada vínculo Ethernet agregado configurado como principal o cliente PTP, puede especificar un vínculo miembro del paquete Ethernet agregado como principal y otro como secundario. PTP cambia al miembro secundario en el paquete de Ethernet agregado cuando el vínculo Ethernet agregado principal está inactivo. Para proporcionar redundancia a nivel de vínculo y de FPC, las interfaces principal y secundaria del paquete Ethernet agregado deben configurarse en tarjetas de línea independientes. Si tanto la principal como la secundaria se configuran en la misma tarjeta de línea, solo se 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 Ethernet agregado PTP activo. La tarjeta de línea del cliente PTP que contiene este vínculo Ethernet agregado PTP activo recibirá paquetes de anuncio y sincronización de la unidad primaria remota.
Consulte la página Explorador de características para confirmar la compatibilidad de la plataforma y la versión para características específicas.
Descripción general de PTP Trace
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 sincronización de 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 (el oscilador de reloj interno del router) de forma discontinua, recibiendo señales de reloj del reloj primario en períodos de tiempo irregulares, o ajustando el bucle de bloqueo 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 retardo de paquetes, la calidad del oscilador utilizado, la asimetría de la red, etc.
Puede implementar un mecanismo de seguimiento de ruta para detectar bucles PTP que circulan sin cesar 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 rastreo de ruta 1588v2 para evitar los bucles PTP y proporcionar convergencia PTP en caso de cualquier error de punto único.
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 referencia múltiple en una red IPv4. Las secciones también explican el estado estable y el manejo de fallas en una topología de anillo PTP:
- Topología de anillo PTP
- Mecanismo de seguimiento de rutas para controlar errores de PTP
- Estado de equilibrio
- Manejo de fallas
- Topología de anillo PTP sin mecanismo de rastreo de ruta
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 relojes de límite (BC1 a BC5) impulsados por un reloj de referencia PTP primario 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 más alto que el del reloj de GM-B.
Cada reloj de límite en el anillo PTP está configurado como cliente y principal para su vecino inmediato para proporcionar un cambio de reloj de referencia PTP sin problemas en caso de falla de reloj de referencia o 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 rutas para controlar errores 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 del principal al cliente) pueden formarse en un bucle infinito (también llamado bucle PTP) en un rastro de red de relojes de límite. 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 rutas se utiliza para detectar tales bucles.
Un seguimiento de ruta es la ruta que un mensaje de anuncio PTP toma a través de la ruta de red de relojes de límite y se rastrea a través del TLV de seguimiento de ruta en el mensaje de anuncio. Un 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 identificador de reloj de cada reloj de límite que atraviesa un mensaje de anuncio a través del anillo PTP.
Uno de los principales usos del mecanismo de rastreo de ruta es detectar los llamados mensajes de anuncio pícaros que circulan sin cesar en bucles en el anillo PTP de 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 el rastro 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 show ptp path-trace detail.
-
Durante GRES, el seguimiento de ruta y la mejor información del algoritmo de reloj primario se envían al núcleo. Por lo tanto, esta información también está disponible en el motor de enrutamiento de reserva.
-
Cuando el número de relojes de límite en una topología supera los 20, se elimina el TLV de seguimiento de ruta.
-
Actualmente, la topología de anillo PTP solo se admite para PTP sobre redes IPv4.
Estado de equilibrio
Se considera que el anillo PTP está en estado estacionario u operando normalmente cuando un enrutador, digamos 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, 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 está bloqueado en GM-A, BC2 y BC5 están bloqueados en BC1, BC3 está bloqueado en BC2 y BC4 está bloqueado en BC5. Cuando se implementa el mecanismo de seguimiento de ruta en esta topología de anillo, se asigna un identificador de reloj a cada reloj de límite que, a su vez, se incluye en el TLV de seguimiento de ruta dentro del mensaje de anuncio. Por lo tanto, el TLV de seguimiento de ruta en el mensaje de anuncio que se origina en BC1 tiene su propio identificador 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), y así sucesivamente.
Como el enrutador BC2 es primario para BC1, BC1 recibe constantemente mensajes de anuncio de BC2. Los mensajes de anuncio de BC2 recibidos en BC1 contienen el propio 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 elimina los mensajes de anuncio de BC2. Del mismo modo, BC2 elimina 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 Manejo de errores.
Manejo de fallas
Considere un escenario en el que el enrutador BC1 se bloquea en el anillo PTP ilustrado en la Figura 1. Este error se maneja de la siguiente manera:
-
El enrutador BC2 deja de recibir mensajes de anuncio de BC1.
-
Los mensajes de anuncio que ahora recibe BC2 son solo los enviados por BC3. BC2 descarta estos mensajes de anuncio porque contienen el propio ID de reloj de BC2: CID2.
-
Dado que BC2 no recibe ningún mensaje de anuncio válido, entra en modo de retención y reduce el valor de sus parámetros de anuncio, como la clase de reloj, lo que da como resultado que BC2 anuncie mensajes con una clase de reloj inferior.
-
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.
-
Cuando BC5 finalmente recibe este mensaje de anuncio con el valor de nivel de calidad inferior de BC4, el mejor algoritmo de reloj primario 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.
-
Cuando BC4 recibe este mensaje de anuncio (que contiene información de clase de reloj superior a la que lleva el mensaje de anuncio de BC3), el enrutador BC4 cambia a BC5. Del mismo modo, 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 a una jerarquía de relojes de límite en el sentido de las agujas del reloj. Todo este proceso toma unas pocas decenas de segundos.
Tenga en cuenta que cada cambio de algoritmo de reloj primario PTP en cada reloj límite es perfecto y, por lo tanto, garantiza que el rendimiento del anillo PTP no se degrade. Sin embargo, cuando hay varios errores simultáneos en la topología de anillo (por ejemplo, errores 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 aumentar a 650ns, por ejemplo, entre enrutadores BC2 y BC4. Tenga en cuenta que este tipo de errores múltiples en una topología de anillo es raro.
MTIE es un error de variación de fase máxima que se mide durante un período de tiempo, donde 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 en bucle de BC2. Esto, a su vez, da como resultado que BC2 intente bloquear BC3 (mientras que BC3 ya está bloqueado en BC2) y se crea un interbloqueo PTP. Debido al punto muerto de PTP, hay una deriva significativa del reloj durante un período de tiempo tanto en BC2 como en BC3 y potencialmente en todos los relojes límite que se pueden rastrear hasta BC3.
Tenga en cuenta que cuando aparece el enrutador BC1 bloqueado, elige GM-A como su principal, y envía mensajes de anuncio que llevan información de clase de reloj superior en comparación con los que llevan los mensajes de anuncio enviados por GM-B. El mejor algoritmo de reloj primario del enrutador BC2 determina que los mensajes de anuncio del BC1 contienen información de clase de reloj superior en comparación con BC3, lo que resulta en que BC2 vuelva a BC1. Del mismo modo, BC3 vuelve a BC2. De esta manera, la topología de anillo se restaura a la topología previa 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 secuencias de esa tarjeta de línea pierden sus paquetes de temporización, otra tarjeta de línea de cliente puede hacerse cargo si se ha preparado para hacerlo.
Cuando se configura la redundancia de tarjetas de línea, las secuencias de cliente se crean en las tarjetas de línea adecuadas. En este momento, todas las tarjetas de línea están en modo DPLL. Todas las secuencias del cliente están preparadas 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 primaria al RE. Después de recibir la mejor información primaria de las tarjetas de línea individuales, el RE selecciona la mejor primaria para servir al nodo BC. Esta información se propaga a todas las tarjetas de línea. Una vez que el RE selecciona el mejor primario, se ejecutará la máquina de estado PTP normal.
Si el algoritmo BMCA da como resultado un cambio de flujo y el nuevo flujo cae en una tarjeta de línea diferente, se activará un cambio sin fallas. La nueva tarjeta de cliente puede configurarse en modo PTP puro o híbrido. La tarjeta de cliente antigua puede estar en modo de cliente PTP puro o cliente híbrido. Las tarjetas de línea deben seguir los siguientes pasos:
-
Una transición de tarjeta de línea de cliente debe ocurrir a través del estado de remanente en la tarjeta de línea principal.
-
FSM necesita convertir la tarjeta de línea de cliente antigua al modo primario PTP puro.
-
En la nueva tarjeta de cliente, FSM debe activarse en función del modo de operación híbrido o PTP puro. Todas estas transiciones deben ser sin hits.
- La redundancia de la tarjeta de línea limitada es compatible con las 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 tarjeta de línea no es sin hits.
- La configuración de puerto esclavo o de estado en más de dos líneas no es compatible con las plataformas de enrutamiento universal MX960, MX480, MX240, MX2020, MX2010 MX10003 y MX2008. Esta limitación no se aplica a las plataformas MX10K (MX10008, MX10016 y MX10004.
Temporización de defectos y gestión de eventos en plataformas de enrutamiento
Junos OS para enrutadores metropolitanos universales ACX admite capacidades de gestió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 temporización y eventos de temporización) que se generan, se registra un mensaje en el archivo clksyncd (var/log/clksyncd).
A partir de la versión 24.2R1 de Junos Evolved, los dispositivos ACX7332 y ACX7348 admiten capacidades adicionales de administración de defectos para la SYNCE, PTP MIB (capturas SNMP) y muestran mensajes de error para las funciones de temporización. Para obtener más información, consulte SNMP MIB para conocer la temporización en plataformas de enrutamiento.
La Tabla 1 muestra la lista de notificaciones de captura SNMP para eventos y defectos de temporización admitidos en los enrutadores Metro universales ACX.
| Captura SNMP |
Tipo de notificación |
Descripción |
|---|---|---|
| jnxTimingFaultLOS |
Defectos: Poner Claro |
Denota pérdida de señal Indica que la pérdida de señal se borra |
| jnxTimingFaultEFD |
Defectos (establecidos, borrados) |
Denota desviación de frecuencia excedida |
| jnxTimingFaultLOESMC |
Defectos (establecidos, borrados) |
Denota pérdida del canal de mensajes de sincronización Ethernet (ESMC) |
| jnxTimingFaultQLFail |
Defectos (establecidos, borrados) |
Denota falla en el nivel de calidad |
| jnxTimingFaultLTI |
Defectos (establecidos, borrados) |
Denota pérdida de información de temporización |
| jnxTimingFaultPriSrcFailed |
Defectos |
Denota el fallo de la fuente primaria |
| jnxTimingFaultSecSrcFailed |
Defectos |
Denota el fallo de la fuente secundaria |
| jnxTimingFaultPtpUniNegRateReject |
Defectos |
Cuando actúa como principal, esta captura SNMP indica un error o rechaza clientes para mensajes de señalización. Cuando actúa como cliente, esta captura SNMP indica un error o un cliente que deja de recibir mensajes de señalización |
| jnxTimingEventPriSrcRecovered |
Eventos |
Denota la recuperación de la fuente primaria |
| jnxTimingEventSecSrcRecovered |
Eventos |
Denota la recuperación de fuente secundaria |
| jnxTimingEventPriRefChanged |
Eventos |
Denota 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 |
Denota un cambio en la referencia secundaria, como un cambio en la interfaz lógica |
| jnxTimingEventQLChangedRx (ACX7332, ACX7348) |
Eventos |
Denota un cambio en el nivel de calidad en Receiver SSM/ESMC |
| jnxTimingEventQLChangedTx (ACX7332, ACX7348) | Eventos | Denota un cambio en el nivel de calidad en el transmisor SSM/ESMC |
| jnxTimingEventDpllStatus |
Eventos |
Indica el estado DPLL (SyncE, BITS, híbrido) |
| jnxTimingEventSynceDpllStatus (ACX7332, ACX7348) | Eventos | Indica los siguientes estados DPLL de SyncE: jnxClksyncIfIndex: la frecuencia se deriva de este índice de interfaz. jnxClksyncIntfName: la frecuencia se deriva de este nombre de interfaz. jnxClksyncDpllState: estado de DPLL. jnxClksyncDpllStateStr: estado de DPLL en formato de cadena. |
| jnxTimingEventPtpServoStatus |
Eventos |
Denota los siguientes estados de servo PTP:
|
| jnxTimingEventPtpClockClassChange |
Eventos |
Denota un cambio en la clase de reloj PTP |
| jnxTimingEventPtpClockAccuracyChange |
Eventos |
Denota un cambio en la precisión del PTP |
| jnxTimingEventPtpGMChange |
Eventos |
Denota un cambio en el reloj de referencia PTP |
| jnxTimingEventHybridStatus |
Eventos |
Denota los siguientes estados híbridos:
|
Para configurar y generar notificaciones de captura de eventos y defectos de temporización, 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:
[edit]
snmp {
trap-group <group-name> {
categories {
timing-events;
}
}
}
A continuación se muestra un ejemplo de configuración para la temporización SNMP en enrutadores de la serie ACX:
snmp {
trap-options {
source-address 10.216.66.139;
}
trap-group timingGroup {
version v2;
destination-port 8999;
categories {
timing-events;
}
targets {
192.168.120.129;
}
}
traceoptions {
flag all;
}
}
SNMP MIB para temporización en plataformas de enrutamiento
Junos OS para enrutadores metropolitanos universales ACX admite las capacidades de gestión de obtención, siguiente y caminata SNMP para las funciones de temporización. Estas capacidades se habilitan a través de los objetos de temporización PTP MIB, SyncE MIB y GPS MIB.
Los objetos de temporización PTP MIB y SyncE MIB se agrupan bajo el jnxTimingNotfObjects objeto SNMP MIB.
La Tabla 1 muestra la lista de objetos SNMP MIB admitidos para la administración SNMP get, get-next y walk en enrutadores Metro universales ACX.
| SNMP MIB |
Objeto |
Descripción |
|---|---|---|
| PTP MIB |
jnxPtpServoState |
Denota los siguientes estados de servo PTP:
|
| jnxPtpServoStateStr |
Indica la cadena de estado del servo PTP:
|
|
| jnxPtpClass |
Denota la clase del reloj de referencia PTP. |
|
| jnxPtpGmId |
Indica el identificador de reloj de referencia PTP. |
|
| (ACX7332, ACX7348) | ||
| jnxPtpPhaseOffset | Denota el desplazamiento de fase PTP. | |
| jnxPtpUtcOffset | Denota el desplazamiento UTC PTP. | |
| jnxPtpAdvClockClass | Denota la clase de reloj PTP anunciada. | |
| jnxTimingFrequencyTrazabilidad | Denota el indicador de trazabilidad de frecuencia. | |
| jnxTimingTimeTrazabilidad | Denota el indicador de trazabilidad temporal. | |
| jnxClksyncPtpOperationalMasters | Denota los maestros operativos del PTP. | |
| jnxClksyncPtpOperationalSlaves | Denota los esclavos operativos PTP. | |
| MIB de sincronización |
jnxClksyncQualityCode |
Indica el nivel de calidad de SSM/ESMC del origen bloqueado en formato decimal. |
| jnxClksyncQualityCodeStr |
Denota el nivel de calidad de SSM/ESMC del origen bloqueado en formato de cadena |
|
| jnxClksyncIfIndex |
Denota el índice de interfaz del origen bloqueado en formato decimal. |
|
| jnxClksyncIntfName |
Indica el nombre de interfaz del origen bloqueado en formato de cadena. |
|
| (ACX7332, ACX7348) | ||
| jnxClksyncSynceQualityTable | Denota la tabla SyncE para obtener métricas de calidad para todos los orígenes configurados. | |
| jnxClksyncSynceQualityEntry | Indica la entrada de tabla SyncE para obtener métricas de calidad para todos los orígenes configurados. | |
| jnxClksyncSynceQualityIntfName | Indica el nombre de interfaz del origen configurado. | |
| jnxClksyncSynceQualityValue | Denota el nivel de calidad del origen configurado. | |
| jnxClksyncSynceLockedIfIndex | Denota el ifIndex SNMP bloqueado de la interfaz miembro. | |
| jnxClksyncSynceLockedIntfName |
Indica el nombre de la interfaz SyncE. | |
| jnxClksyncDpllState | Denota los estados DPLL de SyncE. | |
| jnxClksyncDpllStateStr |
Indica el estado DPLL en formato de cadena. | |
| GPS MIB |
jnxGpsRecvStatus |
Muestra el estado del receptor GPS. |
-
La administración de obtención y caminata SNMP solo se admite para objetos escalares.
Utilice los
show snmp mib get>comandos yshow snmp mib walk <oid>para ver los objetos SNMP MIB configurados. -
Para los objetos SyncE, los objetos jnxClksyncQualityCode, jnxClksyncQualityCodeStr, jnxClksyncIfIndex y jnxClksyncIntfName solo se muestran para el origen bloqueado.
- Para obtener más información, consulte Temporización de MIB y notificaciones.
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 show con fines de supervisión y solución de problemas.
A continuación se muestran los resultados del comando show de ejemplo como referencia:
Mostrar amplia sincronización del chasis
user@host> show chassis synchronization extensive Current clock status : Locked Clock locked to : Primary SNMP trap status : Enabled Configured sources: Interface : ge-0/0/7 Status : Secondary Index : 136 Clock source state : Clk qualified Priority : Default(8) Configured QL : SEC ESMC QL : PRC Clock source type : ifd Clock Event : Clock qualified Interface State : Up,sec,ESMC Rx(SSM 0x2),ESMC TX(QL SEC/SSM 0xb), Interface : ge-0/1/1 Status : Primary Index : 138 Clock source state : Clk qualified Priority : Default(8) Configured QL : PRC ESMC QL : PRC Clock source type : ifd Clock Event : Clock locked Interface State : Up,pri,ESMC Rx(SSM 0x2),ESMC TX(QL DNU/SSM 0xf)
Mostrar amplia sincronización del chasis
user@host> show chassis synchronization extensive Configured ports: Name : auxiliary Rx status : active Rx message : TL000001433759011353 Current ToD : Mon Jun 8 10:23:31 2015 Last ToD update : Mon Jun 8 10:23:30 2015 GPS receiver status : Lost Sync UTC Pending : FALSE UTC Offset : 35 One PPS status : Active Configured sources: Interface : gps Status : Primary Index : 1 Clock source state : Clk failed Priority : Default(6) Configured QL : PRC ESMC QL : DNU Clock source type : extern Clock Event : Clock failed Interface State : Up,pri
Mostrar detalles del estado de bloqueo PTP
user@host> show ptp lock-status detail Lock Status: Lock State : 1 (FREERUN) Phase offset : 0.000000000 sec State since : 2015-05-04 03:13:49 PDT (00:01:45 ago) Selected Master Details: Upstream Master address : 61.1.1.2 Slave interface : ge-0/1/1.0 Parent Id : 40:b4:f0:ff:fe:42:f5:00 GMC Id : 40:b4:f0:ff:fe:42:d5:00
mostrar snmp mib obtener <MIB-timing-objects>
user@host> show snmp mib get jnxGpsRecvStatus.0 jnxGpsRecvStatus.0 = Lost Sync
show snmp mib walk jnxTimingNotfObjects
user@host> show snmp mib walk jnxTimingNotfObjects jnxClksyncIfIndex.0 = 138 jnxClksyncIntfName.0 = ge-0/1/1 jnxClksyncQualityCode.0 = 2 jnxPtpServoState.0 = 1 jnxPtpClass.0 = 6 jnxPtpGmId.0 = 40:b4:f0:ff:fe:42:d5:00 jnxClksyncQualityCodeStr.0 = PRC jnxPtpServoStateStr.0 = FREERUN
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 redes de retorno móvil.
La función APTS solo se admite en Junos OS versión 12.3X54–D25 para 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 actúa como principal PTP.
APTS utiliza GNSS como referencia de tiempo principal en ubicaciones de sitios celulares o en un punto de agregación cercano a los sitios celulares. APTS utiliza la distribución de temporización basada en la red para ayudar y mantener la temporización durante los períodos de retención cuando GNSS no está disponible.
Para admitir esta característica, necesita un nodo APTS con origen GNSS configurado en el nivel de jerarquía [edit chassis synchronization] y 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
[edit chassis]
synchronization {
network-option <option-1 | option-2>;
port gnss {
client {
constellation <constellation-type>;
anti-jamming;
}
}
esmc-transmit {
interface <interfaces-name>;
}
}
Configuración de PTPoE
[edit protocols]
ptp {
clock-mode boundary;
slave {
interface <slave-ptp-ifl> {
multicast-mode {
transport ieee-802.3 [ link-local ] ;
}
}
}
master {
interface <master-ptp-ifl> {
multicast-mode {
transport ieee-802.3 [ link-local ] ;
}
}
}
Configuración de PTPoIP
[edit protocols]
clock-mode boundary;
slave {
interface <logical-interface-name> {
unicast-mode {
transport ipv4;
clock-source <remote-master-ip-address> local-ip-address <local-slave-ip-address>;
}
}
}
master {
interface <logical-interface-name>{
unicast-mode {
transport ipv4;
clock-client <remote-slave-ip> local-ip-address <local-master-ip>;
}
}
}
}
La prioridad de la fuente de reloj sería GNSS primero y luego PTP.
Puede usar los show ptp lock-status detailcomandos , show chassis synchronization extensivey show chassis synchronization gnss extensive show para supervisar y solucionar problemas de configuración.
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 con capacidad 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 sincronizados con un satélite GPS. El enrutador de la serie ACX tiene un conector Subminiatura versión B (SMB) que puede tomar 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 instrucción y las gps opciones en el nivel jerárquico [edit chassis synchronization source].
Los enrutadores ACX500 no requieren un receptor GPS externo porque el receptor GPS está integrado en el sistema.
Sistema mundial integrado de navegación por satélite (GNSS) 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 con capacidad 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 la entrada GNSS a través del conector Subminiatura versión A (SMA). Puede configurar el puerto GNSS y sus parámetros asociados en el nivel jerárquico [editar sincronización del chasis].
Puede configurar el puerto GNSS incluyendo la constellation gps] instrucción CLI en el nivel jerárquico [edit chassis synchronization port gnss]. Si no especifica una constellation opción, la opción de gps constelación se considera de forma predeterminada.
El siguiente es el nivel de jerarquía [edit chassis synchronization port gnss]:
[edit chassis synchronization]
port gnss client {
cable-length-compensation {
time delay-in-nanoseconds;
}
constellation [gps];
anti-jamming;
}
-
El rango para
cable-length-compensationes 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 es compatible con puertos 1G en todas las plataformas. Consulte Características de PTP y plataformas compatibles para obtener información sobre las plataformas PTP y las características 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 de chasis.