Routers : Cisco Carrier Routing System

Mejores prácticas de funcionamiento de CRS-1 e IOS XR

1 Mayo 2008 - Traducción manual
Otras Versiones: PDFpdf | Traducción Automática (31 Julio 2013) | Inglés (1 Noviembre 2006) | Comentarios


Contenido

Introducción
Requisitos previos
      Requerimientos
      Componentes utilizados
      Convenciones
Información general de Cisco IOS XR
Proceso y cadenas
Estados del proceso y de las cadenas
      Envío de mensajes síncronos
Proceso bloqueado y estados de proceso
Procesos importantes y funciones
      Netio
      Group Services Process (GSP)
      Bulk Content Downloader (BCDL)
      Lightweight Messaging (LWM)
      Envmon
Introducción a la estructura de CRS-1
      Plano de estructura
      Supervisión de estructura
Información general de planos de control
      Configuración de Catalyst 6500
      Administración de planos de control de chasis múltiple
ROMMON y monlib
      Instrucciones de actualización
Información general de PLIM y MSC
Exceso de suscripción de PLIM
Administración de la configuración
Seguridad
      LPTS
Reenvío de paquetes internos
Fuera de banda

Introducción

Este documento ayuda a comprender los siguientes elementos:

  • Proceso y cadenas

  • Estructura de CRS-1

  • Plano de control

  • Rommon y monlib

  • Módulo de interfaz de capa física (PLIM) y Modular Service Card (MSC)

  • Administración de la configuración

  • Seguridad

  • Fuera de banda

  • Protocolo de administración de red simple (SNMP)

Requisitos previos

Requerimientos

Cisco recomienda que se tengan conocimientos de Cisco IO® XR.

Componentes utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware:

  • Software Cisco IOS XR

  • CRS-1

La información que contiene este documento se creó a partir de los dispositivos en un entorno de laboratorio específico. Todos los dispositivos que se utilizan en este documento se iniciaron con una configuración sin definir (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.

Convenciones

Consulte Convenciones sobre consejos técnicos de Cisco para obtener más información sobre las convenciones del documento.

Información general de Cisco IOS XR

Cisco IOS XR está diseñado para ofrecer escalabilidad. El kernel es una arquitectura de microkernel, por lo que sólo proporciona servicios básicos, como administración de procesos, planificación, señales y temporizadores. El resto de servicios, como sistemas de archivos, controladores, pilas de protocolos y aplicaciones, se consideran administradores de recursos y se ejecutan en el espacio de memoria protegido. Estos servicios se pueden agregar o eliminar en el tiempo de ejecución, según el diseño del programa. La huella del microkernel es sólo de 12 kb. El microkernel y el sistema operativo subyacente, que pertenecen a QNX Software Systems, se denominan Neutrino. QNX está especializada en el diseño de sistemas operativos en tiempo real. El microkernel es preferente y el planificador se basa en prioridades. Esto asegura una conmutación entre procesos muy rápida y que las cadenas con la mayor prioridad siempre tengan acceso a la CPU cuando sea necesario. Éstas son algunas de las ventajas de las que se beneficia Cisco IOS XR. Sin embargo, la principal ventaja es el diseño heredado de comunicaciones interprocesos en el núcleo de los sistemas operativos.

Neutrino es un sistema operativo de envío de mensajes y los mensajes son el medio básico de las comunicaciones interprocesos entre todas las cadenas. Cuando un servidor en concreto desea proporcionar un servicio, crea un canal para el intercambio de mensajes. Los clientes se conectan al canal de servidores efectuando las asignaciones directamente al descriptor del archivo relevante, a fin de utilizar el servicio. Todas las comunicaciones entre cliente y servidor se realizan mediante el mismo mecanismo. Esto es una gran ventaja para un equipo de alta calidad, como el CRS-1. Tenga en cuenta los siguientes puntos cuando realice una operación de lectura local en un kernel de UNIX estándar:

  • El software interrumpe el kernel.

  • El kernel envía información al sistema de archivos.

  • Se reciben los datos.

Tenga en cuenta los siguientes puntos en los casos remotos:

  • El software interrumpe el kernel.

  • El kernel envía información al sistema NFS.

  • NFS llama al componente de red.

  • El sistema remoto envía información al componente de red.

  • Se llama a NFS.

  • El kernel envía información al sistema de archivos.

La semántica de la lectura local y de la lectura remota no es igual. Los argumentos y los parámetros para los permisos de bloqueo de archivos y de configuración son diferentes.

Tenga en cuenta el caso local de QNX:

  • El software interrumpe el kernel.

  • El kernel realiza el envío de mensajes al sistema de archivos.

Tenga en cuenta el caso no local:

  • El software interrumpe el kernel.

  • Kernel entra en QNET, que es el mecanismo de transporte para la IPC.

  • QNET accede al kernel.

  • El kernel envía información al sistema de archivos.

Toda la semántica relacionada con los parámetros de envío de argumentos y del sistema de archivos es idéntica. Todo se ha desconectado en la interfaz de IPC, lo que permite que el cliente y el servidor estén completamente separados. Esto permite que se pueda ejecutar cualquier proceso en cualquier momento y lugar. Si un procesador de ruta está demasiado ocupado atendiendo solicitudes, es posible migrar fácilmente tales servicios a una CPU diferente que se ejecute en DRP. Un equipo de alta calidad que ejecute diferentes servicios en distintas CPU se reparte en diferentes nodos que se pueden comunicar fácilmente con otros nodos. La infraestructura permite la escalabilidad. Cisco ha aprovechado esta ventaja y ha escrito software adicional que conecta con las principales operaciones del kernel de envío de mensajes, lo que permite al router de CRS escalar a miles de nodos; cada nodo, en este caso una CPU, ejecuta una instancia del OS, tanto si es un procesador de ruta (RP), un procesador Distributed Route Processor (DRP), una tarjeta Modular Services Card (MSC) o un procesador de switch (SP).

Proceso y cadenas

Dentro de los límites de Cisco IOS XR, un proceso es un área de memoria protegida que contiene una o varias cadenas. Desde el punto de vista de los programadores, las cadenas realizan el trabajo y cada una completa una ruta de ejecución lógica para realizar una tarea específica. La memoria que requieren las cadenas durante el flujo de ejecución pertenece al proceso dentro del cual operan y está protegida frente a las cadenas de cualquier otro proceso. Una cadena es una unidad de ejecución con un contexto de ejecución que incluye una pila y registros. Un proceso es un grupo de cadenas que comparte un espacio de dirección virtual; aunque también puede incluir una sola cadena, lo más frecuente es que contenga varias. Si otra cadena de un proceso distinto intenta escribir en la memoria del proceso, se extermina el proceso amenazante. Si dentro de un proceso operan varias cadenas, dichas cadenas tendrán acceso a la misma memoria del proceso y, como resultado, podrán sobrescribir los datos de otra cadena. Se deben completar los pasos de un procedimiento a fin de mantener la sincronización con los recursos, para evitar estas cadenas dentro del mismo proceso.

Las cadenas utilizan un objeto denominado exclusión mutua (MUTEX) con el fin de garantizar la exclusión mutua a los servicios. Una cadena con el objeto MUTEX puede escribir en un área concreta de la memoria, por ejemplo. Las cadenas que no tengan el objeto MUTEX no pueden. También hay otros mecanismos que permiten garantizar la sincronización con los recursos: semáforos, variables condicionales o condvar, barreras y sleepons. No se tratan aquí, aunque proporcionan servicios de sincronización como parte de sus tareas. Si equipara los principios que aquí se tratan con Cisco IOS, Cisco IOS es un solo proceso en el que operan muchas cadenas, todas ellas con acceso al mismo espacio de memoria. Sin embargo, la diferencia es que Cisco IOS llama a estos procesos de cadenas.

Estados del proceso y de las cadenas

En Cisco IOS XR, hay servidores que proporcionan los servicios y los clientes que utilizan los servicios. Un proceso determinado puede tener una serie de cadenas que proporcionan el mismo servicio. Otro proceso puede tener una serie de clientes que podrían requerir un servicio determinado en cualquier momento. El acceso a los servidores no siempre está disponible y si un cliente solicita acceso a un servicio, espera a que el servidor esté libre. En este caso, se dice que el cliente está bloqueado. Este estado se denomina modelo de cliente/servidor de bloqueo. El cliente puede estar bloqueado porque espera un recurso como un objeto MUTEX, o bien porque el servidor aún no haya respondido.

Para comprobar el estado de las cadenas del proceso ospf, ejecute un comando show process ospf:

RP/0/RP1/CPU0:CWDCRS#show process ospf
                  Job Id: 250
                     PID: 110795
         Executable path: /disk0/hfr-rout-3.2.3/bin/ospf
              Instance #: 1
              Version ID: 00.00.0000
                 Respawn: ON
           Respawn count: 1
  Max. spawns per minute: 12
            Last started: Tue Jul 18 13:10:06 2006
           Process state: Run
           Package state: Normal
       Started on config: cfg/gl/ipv4-ospf/proc/101/ord_a/routerid
                    core: TEXT SHAREDMEM MAINMEM
               Max. core: 0
               Placement: ON
            startup_path: /pkg/startup/ospf.startup
                   Ready: 1.591s
               Available: 5.595s
        Process cpu time: 89.051 user, 0.254 kernel, 89.305 total
JID    TID  Stack pri state        HR:MM:SS:MSEC NAME
250    1      40K  10 Receive       0:00:11:0509 ospf
250    2      40K  10 Receive       0:01:08:0937 ospf
250    3      40K  10 Receive       0:00:03:0380 ospf
250    4      40K  10 Condvar       0:00:00:0003 ospf
250    5      40K  10 Receive       0:00:05:0222 ospf

Tenga en cuenta que el proceso ospf tiene una ID de trabajo (JID) que es 250. Ésta no cambia nunca en un router en ejecución ni, en general, en ninguna versión en particular de Cisco IOS XR. Dentro del proceso ospf hay cinco cadenas, cada una con su propia ID de cadena (TID). Se muestra el espacio de pila, la prioridad y el estado de cada cadena.

Envío de mensajes síncronos

Ya se ha indicado anteriormente que QNX es un sistema operativo de envío de mensajes. En realidad, es un sistema operativo de envío de mensajes síncronos. Gran parte de los problemas del sistema operativo se reflejan en la mensajería síncrona. No es que el envío de mensajes provoque problemas, sino que los síntomas de los problemas se reflejan en el envío de mensajes síncronos. Gracias a esta sincronización, el operador de CRS-1 puede acceder fácilmente a la información de vida útil o estado, lo que facilita el proceso de resolución de problemas. La vida útil del envío de mensajes se asemeja al siguiente proceso:

  • Un servidor crea un canal de mensaje.

  • Un cliente se conecta al canal de un servidor (análogo al posix abierto).

  • Un cliente envía un mensaje a un servidor (MsgSend) y mientras espera una respuesta se bloquea.

  • El servidor recibe (MsgReceive) un mensaje de un cliente, procesa el mensaje y responde al cliente.

  • El cliente desbloquea y procesa la respuesta del servidor.

Este modelo de cliente/servidor de bloqueo es el envío de mensajes síncronos. De esta forma, se permite que el cliente envíe un mensaje y se bloquee. El servidor recibe el mensaje, lo procesa, responde al cliente y, a continuación, el cliente se desbloquea. Éstos son los detalles específicos:

  • El servidor espera en estado RECEIVE.

  • El cliente envía un mensaje al servidor y pasa al estado de bloqueo BLOCKED.

  • El servidor recibe el mensaje y se desbloquea, en caso de que espere en estado de recepción (RECEIVE).

  • El cliente pasa al estado de respuesta REPLY.

  • El servidor pasa al estado de ejecución RUNNING.

  • El servidor procesa el mensaje.

  • El servidor responde al cliente.

  • El cliente se desbloquea.

Para ver los estados del cliente y del servidor, ejecute el comando show process.

RP/0/RP1/CPU0:CWDCRS#show processes
JID    TID  Stack pri state        HR:MM:SS:MSEC NAME
1      1       0K  0  Ready       320:04:04:0649 procnto-600-smp-cisco-instr
1      3       0K  10 Nanosleep     0:00:00:0043 procnto-600-smp-cisco-instr
1      5       0K  19 Receive       0:00:00:0000 procnto-600-smp-cisco-instr
1      7       0K  19 Receive       0:00:00:0000 procnto-600-smp-cisco-instr
1      8       0K  19 Receive       0:00:00:0000 procnto-600-smp-cisco-instr
1      11      0K  19 Receive       0:00:00:0000 procnto-600-smp-cisco-instr
1      12      0K  19 Receive       0:00:00:0000 procnto-600-smp-cisco-instr
1      13      0K  19 Receive       0:00:00:0000 procnto-600-smp-cisco-instr
1      14      0K  19 Receive       0:00:00:0000 procnto-600-smp-cisco-instr
1      15      0K  19 Receive       0:00:00:0000 procnto-600-smp-cisco-instr
1      16      0K  10 Receive       0:02:01:0207 procnto-600-smp-cisco-instr
1      17      0K  10 Receive       0:00:00:0015 procnto-600-smp-cisco-instr
1      21      0K  10 Receive       0:00:00:0000 procnto-600-smp-cisco-instr
1      23      0K  10 Running       0:07:34:0799 procnto-600-smp-cisco-instr
1      26      0K  10 Receive       0:00:00:0001 procnto-600-smp-cisco-instr
1      31      0K  10 Receive       0:00:00:0001 procnto-600-smp-cisco-instr
1      33      0K  10 Receive       0:00:00:0000 procnto-600-smp-cisco-instr
1      39      0K  10 Receive       0:13:36:0166 procnto-600-smp-cisco-instr
1      46      0K  10 Receive       0:06:32:0015 procnto-600-smp-cisco-instr
1      47      0K  56 Receive       0:00:00:0029 procnto-600-smp-cisco-instr
1      48      0K  10 Receive       0:00:00:0001 procnto-600-smp-cisco-instr
1      72      0K  10 Receive       0:00:00:0691 procnto-600-smp-cisco-instr
1      73      0K  10 Receive       0:00:00:0016 procnto-600-smp-cisco-instr
1      78      0K  10 Receive       0:09:18:0334 procnto-600-smp-cisco-instr
1      91      0K  10 Receive       0:09:42:0972 procnto-600-smp-cisco-instr
1      95      0K  10 Receive       0:00:00:0011 procnto-600-smp-cisco-instr
1      103     0K  10 Receive       0:00:00:0008 procnto-600-smp-cisco-instr
74     1       8K  63 Nanosleep     0:00:00:0001 wd-mbi
53     1      28K  10 Receive       0:00:08:0904 dllmgr
53     2      28K  10 Nanosleep     0:00:00:0155 dllmgr
53     3      28K  10 Receive       0:00:03:0026 dllmgr
53     4      28K  10 Receive       0:00:09:0066 dllmgr
53     5      28K  10 Receive       0:00:01:0199 dllmgr
270    1      36K  10 Receive       0:00:36:0091 qsm
270    2      36K  10 Receive       0:00:13:0533 qsm
270    5      36K  10 Receive       0:01:01:0619 qsm
270    7      36K  10 Nanosleep     0:00:22:0439 qsm
270    8      36K  10 Receive       0:00:32:0577 qsm
67     1      52K  19 Receive       0:00:35:0047 pkgfs
67     2      52K  10 Sigwaitinfo   0:00:00:0000 pkgfs
67     3      52K  19 Receive       0:00:30:0526 pkgfs
67     4      52K  10 Receive       0:00:30:0161 pkgfs
67     5      52K  10 Receive       0:00:25:0976 pkgfs
68     1       8K  10 Receive       0:00:00:0003 devc-pty
52     1      40K  16 Receive       0:00:00:0844 devc-conaux
52     2      40K  16 Sigwaitinfo   0:00:00:0000 devc-conaux
52     3      40K  16 Receive       0:00:02:0981 devc-conaux
52     4      40K  16 Sigwaitinfo   0:00:00:0000 devc-conaux
52     5      40K  21 Receive       0:00:03:0159 devc-conaux
65545  2      24K  10 Receive       0:00:00:0487 pkgfs
65546  1      12K  16 Reply         0:00:00:0008 ksh
66     1       8K  10 Sigwaitinfo   0:00:00:0005 pipe
66     3       8K  10 Receive       0:00:00:0000 pipe
66     4       8K  16 Receive       0:00:00:0059 pipe
66     5       8K  10 Receive       0:00:00:0149 pipe
66     6       8K  10 Receive       0:00:00:0136 pipe
71     1      16K  10 Receive       0:00:09:0250 shmwin_svr
71     2      16K  10 Receive       0:00:09:0940 shmwin_svr
61     1       8K  10 Receive       0:00:00:0006 mqueue

Proceso bloqueado y estados de proceso

Para ver los procesos que están en estado de bloqueo, ejecute el comando show process blocked.

RP/0/RP1/CPU0:CWDCRS#show processes blocked
  Jid       Pid Tid                 Name State  Blocked-on
65546      4106   1                  ksh Reply    4104  devc-conaux
  105     61495   2              attachd Reply   24597  eth_server
  105     61495   3              attachd Reply    8205  mqueue
  316     65606   1          tftp_server Reply    8205  mqueue
  233     90269   2              lpts_fm Reply   90223  lpts_pa
  325    110790   1            udp_snmpd Reply   90257  udp
  253    110797   4               ospfv3 Reply   90254  raw_ip
  337    245977   2               fdiagd Reply   24597  eth_server
  337    245977   3               fdiagd Reply    8205  mqueue
65762   5996770   1                 exec Reply       1  kernel
65774   6029550   1                 more Reply    8203  pipe
65778   6029554   1       show_processes Reply       1  kernel
RP/0/RP1/CPU0:CWDCRS#

El envío de mensajes síncronos le permite realizar fácilmente un seguimiento del ciclo de comunicación interprocesos entre las diferentes cadenas. En cualquier momento, una cadena puede estar en un estado específico. Un estado de bloqueo puede ser síntoma de un problema. Esto no significa que si una cadena está en estado de bloqueo, haya un problema, por lo que no tiene que ejecutar el comando show process blocked ni iniciar un caso con el Soporte de Cisco. Las cadenas bloqueadas son algo muy normal.

Observe el resultado anterior. Si observa la primera cadena de la lista, encontrará ksh y su respuesta bloqueada en devc-conaux. El cliente, en este caso ksh, envió un mensaje al proceso devc-conaux, el servidor; éste último tiene la respuesta de ksh bloqueada hasta que responda. Ksh es el shell de UNIX que se utiliza en la consola o en el puerto AUX. Ksh espera la entrada procedente de la consola y, si no hay ninguna porque el operador no escriba, permanece bloqueado hasta que procese alguna entrada. Después del procesamiento, ksh vuelve a la respuesta bloqueada en devc-conaux.

Esto es normal y no muestra ningún problema. El caso es que las cadenas bloqueadas son normales y según la versión de XR, el tipo de sistema, la configuración que se tenga y quién haga qué, se altera el resultado del comando show process blocked. El uso del comando show process blocked es un buen comienzo en la resolución de problemas del OS. Si surge algún problema, por ejemplo, la CPU tiene una actividad alta, utilice el comando anterior para ver si hay algo fuera de lo normal.

Conozca qué es normal en el funcionamiento correcto de su router. A continuación, se muestra una línea de base de referencia que puede utilizar al resolver problemas de ciclos de procesos.

En cualquier momento, una cadena puede estar en un estado específico. La siguiente tabla proporciona una lista de estados:

Si el estado es:

La cadena está:

DEAD

Inactiva. El kernel está esperando a liberar los recursos de las cadenas.

RUNNING

En ejecución en una CPU

READY

Lista para ejecutarse, aunque no se está ejecutando en ninguna CPU

STOPPED

Suspendida (señal SIGSTOP)

SEND

En espera de que un servidor reciba el mensaje

RECEIVE

En espera de que un cliente envíe un mensaje

REPLY

En espera de que un servidor responda al mensaje

STACK

En espera de que se asignen más pilas

WAITPAGE

En espera de que el administrador de procesos resuelva un fallo de la página

SIGSUSPEND

En espera de una señal

SIGWAITINFO

En espera de una señal

NANOSLEEP

Inactiva durante un período de tiempo

MUTEX

En espera de adquirir un objeto MUTEX

CONDVAR

En espera de que se señale una variable condicional

JOIN

En espera de que se finalice otra cadena

INTR

En espera de una interrupción

SEM

En espera de adquirir un semáforo

Procesos importantes y funciones

Cisco IOS XR tiene muchos procesos. Éstos son algunos importantes, con la explicación de sus funciones.

Supervisión de vigilancia de sistema (WDSysmon)

Éste es un servicio proporcionado para la detección de bloqueos de procesos y condiciones de poca memoria. Se puede producir una condición de poca memoria como resultado de una fuga de memoria o de alguna otra circunstancia extraña. Un bloqueo puede ser el resultado de una serie de condiciones como interbloqueos de procesos, bucles infinitos, bloqueos de kernel o errores de planificación. En cualquier entorno de varias cadenas, el sistema puede llegar a un estado desconocido que se denomina condición de interbloqueo o simplemente interbloqueo. Se puede producir cuando una o varias cadenas no pueden continuar por una contención de recursos. Por ejemplo, la cadena A puede enviar un mensaje a la cadena B mientras que la cadena B envía un mensaje a la cadena A simultáneamente. Ambas cadenas se esperan mutuamente y pueden estar en estado de bloqueo de envío y esperar indefinidamente. Éste es un caso simple que implica dos cadenas, pero si un servidor es responsable de un recurso que utilizan muchas cadenas y que está bloqueado en otra cadena, todas aquellas cadenas que soliciten acceso a este recurso recibirán una espera bloqueada en el servidor.

Los interbloqueos se pueden producir entre algunas cadenas, pero, como consecuencia, pueden afectar a otras cadenas. Los interbloqueos se pueden evitar con un buen programa de diseño, sin distinción de la calidad con la que esté diseñado y escrito. A veces una secuencia concreta de eventos que dependen de datos con sincronizaciones específicas, puede provocar un interbloqueo. Los interbloqueos no son siempre determinantes y generalmente son difíciles de reproducir. WDSysmon tiene muchas cadenas; una de ellas se ejecuta con la prioridad más alta que admite Neutrino: 63. La ejecución con la prioridad 63 garantiza que la cadena llegue al tiempo del CPU en un entorno de planificación preferente basado en prioridades. WDSysmon funciona con la capacidad de vigilancia del hardware y vela por los procesos de software que buscan condiciones de bloqueo. Cuando se detectan estas condiciones, WDSysmon recopila más información sobre la condición, puede vaciar la memoria del proceso o del kernel, escribir en syslogs, ejecutar secuencias de comandos y eliminar los procesos interbloqueados. En función de la gravedad del problema, puede iniciar un intercambio de procesador de ruta a fin de mantener el funcionamiento del sistema.

RP/0/RP1/CPU0:CWDCRS#show processes wdsysmon
                  Job Id: 331
                     PID: 36908
         Executable path: /disk0/hfr-base-3.2.3/sbin/wdsysmon
              Instance #: 1
              Version ID: 00.00.0000
                 Respawn: ON
           Respawn count: 1
  Max. spawns per minute: 12
            Last started: Tue Jul 18 13:07:36 2006
           Process state: Run
           Package state: Normal
                    core: SPARSE
               Max. core: 0
                   Level: 40
               Mandatory: ON
            startup_path: /pkg/startup/wdsysmon.startup
            memory limit: 10240
                   Ready: 0.705s
        Process cpu time: 4988.295 user, 991.503 kernel, 5979.798 total

JID    TID  Stack pri state        HR:MM:SS:MSEC NAME
331    1      84K  19 Receive       0:00:00:0029 wdsysmon
331    2      84K  10 Receive       0:17:34:0212 wdsysmon
331    3      84K  10 Receive       0:00:00:0110 wdsysmon
331    4      84K  10 Receive       1:05:26:0803 wdsysmon
331    5      84K  19 Receive       0:00:06:0722 wdsysmon
331    6      84K  10 Receive       0:00:00:0110 wdsysmon
331    7      84K  63 Receive       0:00:00:0002 wdsysmon
331    8      84K  11 Receive       0:00:00:0305 wdsysmon
331    9      84K  20 Sem           0:00:00:0000 wdsysmon

El proceso WDSysmon tiene nueve cadenas. Para la ejecución en la prioridad 10, las prioridades restantes deben ser 11, 19, 20 y 63. Cuando se diseña un proceso, el programador considera detenidamente la prioridad que asigna a cada cadena del proceso. Como se ha explicado anteriormente, el planificador se basa en prioridades, lo que significa que una cadena con prioridad superior está por delante de una con prioridad inferior. La prioridad 63 es la prioridad más alta con la que se puede ejecutar una cadena, en este caso, la cadena 7. La cadena 7 es la cadena vigilante y realiza el seguimiento de los casos de CPU hog. Se debe ejecutar con una prioridad más alta que el resto de cadenas a las que vigila, de lo contrario, podría no ejecutarse, lo que impediría que realizara las tareas para las que está diseñada.

Netio

En Cisco IOS, existen los conceptos de conmutación rápida y de conmutación de procesos. La conmutación rápida utiliza el código CEF y se produce durante la interrupción. La conmutación de procesos utiliza ip_input, que es el código de conmutación de IP y es un proceso planificado. En plataformas de mayor capacidad, la conmutación CEF se realiza en el hardware e ip_input se planifica en la CPU. En Cisco IOS XR, el equivalente de ip_input es Netio.

P/0/RP1/CPU0:CWDCRS#show processes netio
                  Job Id: 241
                     PID: 65602
         Executable path: /disk0/hfr-base-3.2.3/sbin/netio
              Instance #: 1
                    Args: d
              Version ID: 00.00.0000
                 Respawn: ON
           Respawn count: 1
  Max. spawns per minute: 12
            Last started: Tue Jul 18 13:07:53 2006
           Process state: Run
           Package state: Normal
                    core: DUMPFALLBACK COPY SPARSE
               Max. core: 0
                   Level: 56
               Mandatory: ON
            startup_path: /pkg/startup/netio.startup
                   Ready: 17.094s
        Process cpu time: 188.659 user, 5.436 kernel, 194.095 total
JID    TID  Stack pri state        HR:MM:SS:MSEC NAME
241    1     152K  10 Receive       0:00:13:0757 netio
241    2     152K  10 Receive       0:00:10:0756 netio
241    3     152K  10 Condvar       0:00:08:0094 netio
241    4     152K  10 Receive       0:00:22:0016 netio
241    5     152K  10 Receive       0:00:00:0001 netio
241    6     152K  10 Receive       0:00:04:0920 netio
241    7     152K  10 Receive       0:00:03:0507 netio
241    8     152K  10 Receive       0:00:02:0139 netio
241    9     152K  10 Receive       0:01:44:0654 netio
241    10    152K  10 Receive       0:00:00:0310 netio
241    11    152K  10 Receive       0:00:13:0241 netio
241    12    152K  10 Receive       0:00:05:0258 netio

Group Services Process (GSP)

En cualquier equipo de alta calidad, existe una necesidad de comunicación con varios miles de nodos, donde cada uno ejecuta su propia instancia del kernel. En Internet, la comunicación de uno a varios es eficaz si se realiza a través de protocolos de multidifusión. GSP es el protocolo de multidifusión interno que se utiliza para IPC en CRS-1. GSP proporciona una comunicación entre grupos confiable de uno a varios, sin conexión y con semántica asíncrona. Esto permite la escalabilidad de GSP a miles de nodos.

RP/0/RP1/CPU0:CWDCRS#show processes gsp
                  Job Id: 171
                     PID: 65604
         Executable path: /disk0/hfr-base-3.2.3/bin/gsp
              Instance #: 1
              Version ID: 00.00.0000
                 Respawn: ON
           Respawn count: 1
  Max. spawns per minute: 12
            Last started: Tue Jul 18 13:07:53 2006
           Process state: Run
           Package state: Normal
                    core: TEXT SHAREDMEM MAINMEM
               Max. core: 0
                   Level: 80
               Mandatory: ON
            startup_path: /pkg/startup/gsp-rp.startup
                   Ready: 5.259s
               Available: 16.613s
        Process cpu time: 988.265 user, 0.792 kernel, 989.057 total
JID    TID  Stack pri state        HR:MM:SS:MSEC NAME
171    1     152K  30 Receive       0:00:51:0815 gsp
171    3     152K  10 Condvar       0:00:00:0025 gsp
171    4     152K  10 Receive       0:00:08:0594 gsp
171    5     152K  10 Condvar       0:01:33:0274 gsp
171    6     152K  10 Condvar       0:00:55:0051 gsp
171    7     152K  10 Receive       0:02:24:0894 gsp
171    8     152K  10 Receive       0:00:09:0561 gsp
171    9     152K  10 Condvar       0:02:33:0815 gsp
171    10    152K  10 Condvar       0:02:20:0794 gsp
171    11    152K  10 Condvar       0:02:27:0880 gsp
171    12    152K  30 Receive       0:00:46:0276 gsp
171    13    152K  30 Receive       0:00:45:0727 gsp
171    14    152K  30 Receive       0:00:49:0596 gsp
171    15    152K  30 Receive       0:00:38:0276 gsp
171    16    152K  10 Receive       0:00:02:0774 gsp

Bulk Content Downloader (BCDL)

BCDL se utiliza para difundir datos de forma múltiple y confiable a varios nodos, como RP y MSC. Utiliza GSP como transporte subyacente. BCDL garantiza la entrega en orden de los mensajes. En BCDL hay un agente, un productor y un consumidor. El agente es el proceso que se comunica con el productor para recuperar y almacenar en el búfer los datos antes de difundirlos de forma múltiple a los consumidores. El productor es el proceso que produce los datos deseados y el consumidor es el proceso interesado en recibir los datos proporcionados por el productor. BCDL se utiliza durante las actualizares del software Cisco IOS XR.

Lightweight Messaging (LWM)

LWM es una forma de mensajería creada por Cisco y diseñada para crear una capa de abstracción entre las aplicaciones que se comunican entre procesos y Neutrino, con el objetivo de proporcionar independencia al sistema operativo y a la capa de transporte. Si Cisco desea cambiar el proveedor de OS de QNX a algún otro, una capa de abstracción entre las funciones rutinarias del sistema operativo subyacente facilita la independencia del sistema operativo y ayuda a la portabilidad a otro sistema operativo. LWM proporciona una entrega de mensajes síncrona garantizada, que como el envío de mensajes nativo de Neutrino, hace que el emisor se bloquee hasta que el receptor responda.

LWM también proporciona una entrega de mensajes asíncrona mediante pulsos de 40 bits. Los mensajes asíncronos se envían de forma asíncrona, es decir, el mensaje se queda en cola y el emisor no se bloquea, aunque el servidor no los recibe asíncronamente, sino cuando sondea en busca del próximo mensaje disponible. LWM se estructura como cliente/servidor. El servidor crea un canal que sirve de oreja para escuchar los mensajes y espera mientras el bucle realiza una escucha de mensajes recibidos en el canal que acaba de crear. Cuando llega un mensaje, se desbloquea y obtiene un identificador del cliente, que es de hecho lo mismo que la ID de recepción del mensaje recibido. A continuación, el servidor realiza el procesamiento y después responde con un mensaje al identificador del cliente.

En el lado del cliente, realiza una conexión de mensaje. Obtiene el identificador del dispositivo al que se conecta y, a continuación, realiza el envío de un mensaje y se bloquea. Cuando el servidor finaliza el procesamiento, responde y el cliente se desbloquea. Este proceso es virtualmente igual que el envío de mensajes nativo de Neutrino, por lo que la capa de abstracción es muy fina.

LWM se diseña con un número mínimo de llamadas de sistema y de cambios de contexto para ofrecer un alto rendimiento, y es el método preferido de IPC en el entorno de Cisco IOS XR.

Envmon

En el nivel más fundamental, el sistema de supervisión del entorno es responsable de crear advertencias cuando los parámetros físicos, como la temperatura, el voltaje, la velocidad del ventilador, etc., se encuentran fuera de los intervalos de funcionamiento, y se encarga también de apagar el hardware cuando se aproxima a niveles críticos en los que pueda sufrir daños. Supervisa periódicamente cada sensor de hardware disponible, compara el valor que mide con el umbral específico de la tarjeta y genera alarmas, según sea necesario, para realizar la tarea. Se trata de un proceso persistente, que comienza al iniciar el sistema y periódicamente sondea todos los sensores de hardware del chasis, como, por ejemplo, el voltaje, la temperatura, y la velocidad del ventilador, y proporciona estos datos a clientes de administración externos. Además, el proceso periódico compara las lecturas del sensor con los umbrales de alarma y publica alertas de entorno en las bases de datos del sistema para las acciones posteriores del administrador de fallos. Si las lecturas del sensor están peligrosamente fuera del intervalo, el proceso de supervisión del entorno puede hacer que la tarjeta se apague.

Introducción a la estructura de CRS-1

  • Estructura de varias etapas: topología de Benes de 3 etapas

  • Enrutamiento dinámico en la estructura para minimizar la congestión

  • Basada en celdas: celdas de 136 bytes, carga útil de datos de 120 bytes

  • Control de flujo para mejorar el aislamiento de tráfico y minimizar los requisitos de almacenamiento en búfer de la estructura

  • Entrega acelerada etapa a etapa

  • Compatibilidad con dos modos de difusión de tráfico (unidifusión y multidifusión)

  • Compatibilidad con dos prioridades de tráfico por difusión (alta y baja)

  • Compatibilidad con grupos de multidifusión de estructura 1M (FGID)

  • Tolerancia a fallos que afecta al costo: redundancia N+1 o N+k que utiliza planos de estructura en contraposición a 1+1 con un costo mucho mayor

Cuando se realiza una ejecución en modo de chasis único, los ASIC S1, S2 y S3 están situados en las mismas tarjetas de estructura. Esta tarjeta también se denomina tarjeta S123. En una configuración de chasis múltiple, el circuito S2 está separado y se encuentra en el chasis Fabric Card Chassis (FCC). Esta configuración necesita dos tarjetas de estructura para formar un plano, una tarjeta S2 y otra S13. Cada MSC se conecta a ocho planos de estructura a fin de proporcionar redundancia, de manera que si se pierden uno o varios planos, la estructura siga pasando tráfico, a pesar de que el tráfico agregado que puede pasar a través de la estructura sea menor. CRS puede seguir funcionando con la velocidad de línea para la mayoría de tamaños de paquetes con sólo siete planos. La contrapresión se envía a través de la estructura por un plano par e impar. No se recomienda ejecutar un sistema con menos de dos planos, en un plano par e impar. Cualquier configuración con menos de dos planos no es compatible.

Plano de estructura

crs-ios-xr-bp1.gif

El diagrama anterior representa un plano. Hay que multiplicar este diagrama por ocho. Eso significa que el ASIC de sprayer (ingressq) de una LC se conecta a 8 S1 (1 S1 por plano). El S1 de cada plano de la estructura se conecta a 8 sprayers:

  • las 8 LC superiores del chasis

  • las 8 LC inferiores

Hay 16 S1 por cada chasis de 16 ranuras de LC: 8 para las LC superiores (1 por plano) + 8 para las LC inferiores.

En un chasis único de 16 ranuras, una tarjeta de estructura S123 tiene 2 S1, 2 S2 y 4 S3. Esto forma parte de los cálculos de aceleración de la estructura. Hay el doble de cantidad de tráfico que puede salir de la estructura en comparación con el que puede entrar. También, hay dos "sponges" (fabricq) por LC en comparación con "sprayer" 1. Esto permite el almacenamiento en búfer en la LC de salida cuando hay varias LC de entrada que sobrecargan la LC de salida. La LC de salida puede absorber el ancho de banda adicional de la estructura.

Supervisión de estructura

Disponibilidad y conectividad del plano:

admin show controller fabric plane all
admin show controller fabric connectivity all detail

Comprobación de si los planos son celdas de recepción/transmisión y de si se incrementan algunos errores:

admin show controllers fabric plane all statistics

Acrónimos del comando anterior:

  • CE: error corregible

  • UCE: error incorregible

  • PE: error de paridad

No se preocupe si nota algunos errores, ya que esto puede suceder durante el inicio. Los campos no se deben incrementar en tiempo de ejecución. Si se incrementan, puede ser indicativo de que hay un problema en la estructura. Ejecute este comando a fin de obtener un desglose de los errores de cada plano de la estructura:

admin show controllers fabric plane <0-7> statistics detail

Información general de planos de control

La conectividad de un plano de control entre el chasis de la tarjeta de línea y el chasis de la estructura se produce a través de los puertos Gigabit Ethernet en RP (LCC) y SCGE (FCC). La interconexión entre los puertos se produce mediante un par de switches de Catalyst 6500, que se pueden conectar a través de dos o más puertos Gigabit Ethernet.

crs-ios-xr-bp2.gif

Configuración de Catalyst 6500

Ésta es la configuración recomendada para los switches Catalyst que se utiliza para el plano de control del chasis múltiple:

  • Se utiliza una VLAN única en todos los puertos.

  • Todos los puertos se ejecutan en modo de acceso (sin enlace troncal).

  • El árbol de expansión 802.1w/s se utiliza para evitar los bucles.

  • Se utilizan dos o más enlaces para interconectar los dos switches y STP para evitar los bucles. No se recomienda la canalización.

  • Los puertos que se conectan a CRS-1 RP y SCGE utilizan el modo estándar previo, ya que IOS-XR no admite 802.1 basado en normas estándar.

  • UDLD se debe activar en los puertos de conexión entre switches, y entre switches y RP/SCGE.

  • UDLD está desactivado de forma predeterminada en CRS-1.

Consulte Activación del software Cisco IOS XR en un sistema multishelf (en inglés) para obtener más información acerca de cómo configurar Catalyst 6500 en un sistema multishelf.

Administración de planos de control de chasis múltiple

El chasis Catalyst 6504-E, que proporciona la conectividad del plano de control para el sistema de chasis múltiple, está configurado para ofrecer los siguientes servicios de administración:

  • Administración en banda mediante Gigabit de puertos 1/2, que se conecta a un switch LAN en cada PoP. Sólo está permitido el acceso a un pequeño intervalo de subredes y protocolos.

  • NTP se utiliza para establecer la hora del sistema.

  • El uso de syslog se realiza en los hosts estándar.

  • El sondeo y las notificaciones de trampas de SNMP se pueden activar para funciones críticas.

Nota: No se debe realizar ningún cambio en Catalyst durante el funcionamiento. Se debe realizar una prueba previa de cualquier cambio que se vaya a aplicar y se recomienda encarecidamente que esto se haga en una ventana de mantenimiento.

A continuación, se muestra un ejemplo de configuración de administración:

#In-band management connectivity
interface GigabitEthernet2/1
 description *CRS Multi-chassis Management Ethernet - DO NOT TOUCH*
 ip address [ip address] [netmask]
 ip access-group control_only in
!
!
ip access-list extended control_only
 permit udp [ip address] [netmask] any eq snmp
 permit udp [ip address] [netmask] eq ntp any
 permit tcp [ip address] [netmask] any eq telnet

#NTP 

ntp update-calendar
ntp server [ip address]

#Syslog
logging source-interface Loopback0
logging [ip address]
logging buffered 4096000 debugging
no logging console

#RADIUS
aaa new-model
aaa authentication login default radius enable
enable password {password}
radius-server host [ip address] auth-port 1645 acct-port 1646
radius-server key {key}

#Telnet and console access
!
access-list 3 permit [ip address]
!
line con 0
 exec-timeout 30 0
 password {password}
line vty 0 4
 access-class 3 in
 exec-timeout 0 0
password {password}

ROMMON y monlib

monlib de Cisco es un programa ejecutable que se almacena en el dispositivo y se carga en la RAM para que lo ejecute ROMMON. ROMMON utiliza monlib para acceder a los archivos del dispositivo. Las versiones de ROMMON se pueden y deben actualizar si así lo recomienda el Soporte de Cisco. La última versión de ROMMON es la 1.40.

Instrucciones de actualización

Siga estos pasos:

  1. Descargue los binarios de ROMMON de Cisco CRS-1 ROMMON (sólo para clientes registrados).

  2. Descomprima el archivo TAR y copie los 6 archivos BIN en el directorio raíz de CRS de Disk0.

    RP/0/RP0/Router#dir disk0:/*.bin
    
    Directory of disk0:
    
    65920       -rwx  360464      Fri Oct 28 12:58:02 2005  rommon-hfr-ppc7450-sc-dsmp-A.bin
    66112       -rwx  360464      Fri Oct 28 12:58:03 2005  rommon-hfr-ppc7450-sc-dsmp-B.bin
    66240       -rwx  376848      Fri Oct 28 12:58:05 2005  rommon-hfr-ppc7455-asmp-A.bin
    66368       -rwx  376848      Fri Oct 28 12:58:06 2005  rommon-hfr-ppc7455-asmp-B.bin
    66976       -rwx  253904      Fri Oct 28 12:58:08 2005  rommon-hfr-ppc8255-sp-A.bin
    67104       -rwx  253492      Fri Oct 28 12:58:08 2005  rommon-hfr-ppc8255-sp-B.bin
  3. Utilice el comando show diag | inc ROM|NODE|PLIM para ver la versión actual de rommon.

    RP/0/RP0/CPU0:ROUTER(admin)#show diag | inc ROM|NODE|PLIM
    NODE 0/0/SP : MSC(SP)
      ROMMON: Version 1.19b(20050216:033352) [CRS-1 ROMMON]
    PLIM 0/0/CPU0 : 4OC192-POS/DPT
      ROMMON: Version 1.19b(20050216:033559) [CRS-1 ROMMON]
    NODE 0/2/SP : MSC(SP)
      ROMMON: Version 1.19b(20050216:033352) [CRS-1 ROMMON]
    PLIM 0/2/CPU0 : 8-10GbE
      ROMMON: Version 1.19b(20050216:033559) [CRS-1 ROMMON]
    NODE 0/4/SP : Unknown Card Type
    NODE 0/6/SP : MSC(SP)
      ROMMON: Version 1.19b(20050216:033352) [CRS-1 ROMMON]
    PLIM 0/6/CPU0 : 16OC48-POS/DPT
      ROMMON: Version 1.19b(20050216:033559) [CRS-1 ROMMON]
    NODE 0/RP0/CPU0 : RP
      ROMMON: Version 1.19b(20050216:033559) [CRS-1 ROMMON]
    NODE 0/RP1/CPU0 : RP
      ROMMON: Version 1.19b(20050216:033559) [CRS-1 ROMMON]
    NODE 0/SM0/SP : FC/S
      ROMMON: Version 1.19b(20050216:033352) [CRS-1 ROMMON]
    NODE 0/SM1/SP : FC/S
      ROMMON: Version 1.19b(20050216:033352) [CRS-1 ROMMON]
    NODE 0/SM2/SP : FC/S
      ROMMON: Version 1.19b(20050216:033352) [CRS-1 ROMMON]
    NODE 0/SM3/SP : FC/S
    ROMMON: Version 1.19b(20050216:033352) [CRS-1 ROMMON]
  4. Acceda al modo ADMIN y utilice el comando upgrade rommon a all disk0 para actualizar ROMMON.

    RP/0/RP0/CPU0:ROUTER#admin
    RP/0/RP0/CPU0:ROUTER(admin)#upgrade rommon a all disk0 
    Please do not power cycle, reload the router or reset any nodes until
     all upgrades are completed.
    Please check the syslog to make sure that all nodes are upgraded successfully.
    If you need to perform multiple upgrades, please wait for current upgrade
     to be completed before proceeding to another upgrade.
    Failure to do so may render the cards under upgrade to be unusable.
  5. Salga del modo ADMIN e introduzca show log | inc "OK, ROMMON A" y asegúrese de que todos los nodos se actualizan correctamente. Si se produce un fallo en alguno de los nodos, vuelva al paso 4 y realice de nuevo la programación.

    RP/0/RP0/CPU0:ROUTER#show logging | inc "OK, ROMMON A"
    RP/0/RP0/CPU0:Oct 28 14:40:57.223 PST8: upgrade_daemon[380][360]: OK, 
    ROMMON A is programmed successfully. 
    SP/0/0/SP:Oct 28 14:40:58.249 PST8: upgrade_daemon[125][121]: OK, 
    ROMMON A is programmed successfully. 
    SP/0/2/SP:Oct 28 14:40:58.251 PST8: upgrade_daemon[125][121]: OK, 
    ROMMON A is programmed successfully. 
    LC/0/6/CPU0:Oct 28 14:40:58.336 PST8: upgrade_daemon[244][233]: OK, 
    ROMMON A is programmed successfully. 
    LC/0/2/CPU0:Oct 28 14:40:58.365 PST8: upgrade_daemon[244][233]: OK, 
    ROMMON A is programmed successfully. 
    SP/0/SM0/SP:Oct 28 14:40:58.439 PST8: upgrade_daemon[125][121]: OK, 
    ROMMON A is programmed successfully. 
    SP/0/SM1/SP:Oct 28 14:40:58.524 PST8: upgrade_daemon[125][121]: OK, 
    ROMMON A is programmed successfully. 
    LC/0/0/CPU0:Oct 28 14:40:58.530 PST8: upgrade_daemon[244][233]: OK, 
    ROMMON A is programmed successfully. 
    RP/0/RP1/CPU0:Oct 28 14:40:58.593 PST8: upgrade_daemon[380][360]: OK, 
    ROMMON A is programmed successfully. 
    SP/0/6/SP:Oct 28 14:40:58.822 PST8: upgrade_daemon[125][121]: OK, 
    ROMMON A is programmed successfully. 
    SP/0/SM2/SP:Oct 28 14:40:58.890 PST8: upgrade_daemon[125][121]: OK, 
    ROMMON A is programmed successfully. 
    SP/0/SM3/SP:Oct 28 14:40:59.519 PST8: upgrade_daemon[125][121]: OK, 
    ROMMON A is programmed successfully.
  6. Cambie al modo ADMIN y utilice el comando upgrade rommon a all disk0 para actualizar ROMMON.

    RP/0/RP0/CPU0:ROUTER#admin
    RP/0/RP0/CPU0:ROUTER(admin)#upgrade rommon b all disk0 
    Please do not power cycle, reload the router or reset any nodes until
     all upgrades are completed.
    Please check the syslog to make sure that all nodes are upgraded successfully.
    If you need to perform multiple upgrades, please wait for current upgrade
     to be completed before proceeding to another upgrade.
    Failure to do so may render the cards under upgrade to be unusable.
  7. Salga del modo ADMIN e introduzca show log | inc "OK, ROMMON B" y asegúrese de que todos los nodos se actualizan correctamente. Si se produce un fallo en alguno de los nodos, vuelva al paso 4 y realice de nuevo la programación.

    RP/0/RP0/CPU0:Router#show logging | inc "OK, ROMMON B"  
    RP/0/RP0/CPU0:Oct 28 13:27:00.783 PST8: upgrade_daemon[380][360]: OK, 
    ROMMON B is programmed successfully. 
    LC/0/6/CPU0:Oct 28 13:27:01.720 PST8: upgrade_daemon[244][233]: OK, 
    ROMMON B is programmed successfully. 
    SP/0/2/SP:Oct 28 13:27:01.755 PST8: upgrade_daemon[125][121]: OK, 
    ROMMON B is programmed successfully. 
    LC/0/2/CPU0:Oct 28 13:27:01.775 PST8: upgrade_daemon[244][233]: OK, 
    ROMMON B is programmed successfully. 
    SP/0/0/SP:Oct 28 13:27:01.792 PST8: upgrade_daemon[125][121]: OK, 
    ROMMON B is programmed successfully. 
    SP/0/SM0/SP:Oct 28 13:27:01.955 PST8: upgrade_daemon[125][121]: OK, 
    ROMMON B is programmed successfully. 
    LC/0/0/CPU0:Oct 28 13:27:01.975 PST8: upgrade_daemon[244][233]: OK, 
    ROMMON B is programmed successfully. 
    SP/0/6/SP:Oct 28 13:27:01.989 PST8: upgrade_daemon[125][121]: OK, 
    ROMMON B is programmed successfully. 
    SP/0/SM1/SP:Oct 28 13:27:02.087 PST8: upgrade_daemon[125][121]: OK, 
    ROMMON B is programmed successfully. 
    RP/0/RP1/CPU0:Oct 28 13:27:02.106 PST8: upgrade_daemon[380][360]: OK, 
    ROMMON B is programmed successfully. 
    SP/0/SM3/SP:Oct 28 13:27:02.695 PST8: upgrade_daemon[125][121]: OK, 
    ROMMON B is programmed successfully. 
    SP/0/SM2/SP:Oct 28 13:27:02.821 PST8: upgrade_daemon[125][121]: OK, 
    ROMMON B is programmed successfully. 
  8. El comando upgrade sólo graba una sección especial reservada de bootflash con el nuevo valor de ROMMON. Aunque el nuevo valor de ROMMON permanece inactivo hasta que se vuelva a cargar la tarjeta. De manera que, cuando vuelva a cargar la tarjeta, se activa el nuevo ROMMON. Reinicie cada nodo de uno en uno, o simplemente restablezca el router completo con este fin.

    Reload Router:
    RP/0/RP0/CPU0:ROUTER#hw-module node 0/RP0/CPU0 or 0/RP1/CPU0 reload (depends on which on is in Standby Mode.
    RP/0/RP0/CPU0:ROUTER#reload  
    
    !--- Issue right after the first command.
    
    Updating Commit Database.  Please wait...[OK]
    Proceed with reload? [confirm]
    
    
    !--- Reload each Node.  For Fan Controllers (FCx),
    !--- Alarm Modules (AMx), Fabric Cards (SMx), and RPs (RPx), 
    !--- you must wait until the reloaded node is fully reloaded 
    !--- before you reset the next node of the pair.  But non-pairs 
    !--- can be reloaded without waiting.
    
    RP/0/RP0/CPU0:ROUTER#hw-module node 0/RP0/CPU0 or 0/RP1/CPU0 reload 
    
    !--- This depends on which on is in Standby Mode.
    
    RP/0/RP0/CPU0:ROUTER#hw-module node 0/FC0/SP
    RP/0/RP0/CPU0:ROUTER#hw-module node 0/AM0/SP
    RP/0/RP0/CPU0:ROUTER#hw-module node 0/SM0/SP
    
    !--- Do not reset the MSC and Fabric Cards at the same time.
    
    RP/0/RP0/CPU0:ROUTER#hw-module node 0/0/CPU
    
  9. Utilice el comando show diag | inc ROM|NODE|PLIM para comprobar la versión actual de ROMMON.

    RP/0/RP1/CPU0:CRS-B(admin)#show diag | inc ROM|NODE|PLIM
    NODE 0/0/SP : MSC(SP)
      ROMMON: Version 1.32(20050525:193402)  [CRS-1 ROMMON]
    PLIM 0/0/CPU0 : 4OC192-POS/DPT
      ROMMON: Version 1.32(20050525:193559)  [CRS-1 ROMMON]
    NODE 0/2/SP : MSC(SP)
      ROMMON: Version 1.32(20050525:193402)  [CRS-1 ROMMON]
    PLIM 0/2/CPU0 : 8-10GbE
      ROMMON: Version 1.32(20050525:193559)  [CRS-1 ROMMON]
    NODE 0/6/SP : MSC(SP)
      ROMMON: Version 1.32(20050525:193402)  [CRS-1 ROMMON]
    PLIM 0/6/CPU0 : 16OC48-POS/DPT
      ROMMON: Version 1.32(20050525:193559)  [CRS-1 ROMMON]
    NODE 0/RP0/CPU0 : RP
      ROMMON: Version 1.32(20050525:193559)  [CRS-1 ROMMON]
    NODE 0/RP1/CPU0 : RP
      ROMMON: Version 1.32(20050525:193559)  [CRS-1 ROMMON]]
    NODE 0/SM0/SP : FC/S
      ROMMON: Version 1.32(20050525:193402)  [CRS-1 ROMMON]
    NODE 0/SM1/SP : FC/S
      ROMMON: Version 1.32(20050525:193402)  [CRS-1 ROMMON]
    NODE 0/SM2/SP : FC/S
      ROMMON: Version 1.32(20050525:193402)  [CRS-1 ROMMON]
    NODE 0/SM3/SP : FC/S
      ROMMON: Version 1.32(20050525:193402)  [CRS-1 ROMMON]

    Nota: En el chasis de estructura y CRS-8, ROMMON también establece la velocidad del ventilador en la velocidad predeterminada de 4000 RPM.

Información general de PLIM y MSC

A continuación, se representa el flujo del paquete en el router CRS-1 y estos términos son intercambiables:

El ASIC de IngressQ también se denomina ASIC de Sprayer.

El ASIC de FabricQ también se denomina ASIC de Sponge.

El ASIC de EgressQ también se denomina ASIC de Sharq.

SPP también se denomina ASIC de PSE (Packet Switch Engine).

Rx PLIM > Rx SPP > Ingress Q > Fabric > Fabric Q > Tx SPP > Egress Q > Tx PLIM (Sprayer) (Sponge) (Sharq)

crs-ios-xr-bp3.gif

Los paquetes se reciben en el módulo de interfaz de capa física (PLIM).

El PLIM incluye las interfaces físicas de la MSC a la que se acopla. PLIM y MSC son tarjetas independientes conectadas mediante la placa de interconexiones del chasis. Por ello, los tipos de interfaz de una MSC concreta se definen según el tipo de PLIM al que se acopla. En función del tipo de PLIM, la tarjeta contiene una serie de ASIC que proporcionan los medios físicos y el entramado de las interfaces. La finalidad de los ASIC del PLIM es proporcionar la interfaz entre la MSC y las conexiones físicas. Pone fin a la fibra, realiza la conversión eléctrica, pone fin al entramado de los medios SDH/Sonet/Ethernet/HDLC/PPP, realiza la comprobación CRC, agrega alguna información de control, denominada encabezado de búfer, y reenvía los bits que permanecen en la MSC. El PLIM no origina ni recibe las señales de mantenimiento de HDLC ni PPP. Éstas las manipula la CPU en la MSC.

El PLIM también ofrece las siguientes funciones:

  • Filtro de MAC para Gigabit Ethernet de 1/10

  • Entrada/salida de contabilidad de MAC para Gigabit Ethernet de 1/10

  • Filtro de VLAN para Gigabit Ethernet de 1/10

  • Contabilidad de VLAN para Gigabit Ethernet de 1/10

  • Almacenamiento en búfer de entradas y notificación de congestión

crs-ios-xr-bp4.gif

Exceso de suscripción de PLIM

PLIM de 10 GE

El PLIM de 8 X 10 G ofrece la capacidad de completar aproximadamente 80 Gbps de tráfico, mientras que la capacidad máxima de reenvío de la MSC es de 40 Gbps. Si se llenan todos los puertos disponibles del PLIM, se produce un exceso de suscripción y el modelo de QoS pasa a ser extremadamente importante para garantizar que el tráfico más importante no se omita sin querer. A veces, el exceso de suscripción no es una opción y se debe evitar. Para que esto sea posible, sólo se deben utilizar cuatro de los ocho puertos. Además, se debe tener cuidado para garantizar que el ancho de banda óptimo de MSC y PLIM esté disponible para cada uno de los cuatro puertos.

Nota: La asignación de puertos cambia a partir de la versión 3.2.2. Consulte los diagramas.

Asignación de puertos hasta la versión 3.2.1

crs-ios-xr-bp5.gif

Asignación de puertos a partir de la versión 3.2.2

crs-ios-xr-bp6.gif

Como se ha indicado anteriormente, a los puertos físicos los atiende uno de los dos ASIC de FabricQ. La asignación de puertos de ASIC se define estadísticamente y no se puede alterar. Además, el PLIM de 8 X 10 G tiene dos ASIC de PLA. El primer PLA atiende a los puertos del 0 al 3, el segundo atiende del 4 a 7. La capacidad de ancho de banda de un solo PLA del PLIM de 8 X 10 G es de aproximadamente 24 Gbps. La capacidad de conmutación de un solo ASIC de FabricQ es de aproximadamente 62 Mpps.

Si se llenan los puertos del 0 al 3 o del 4 al 7, se reparte la capacidad de ancho de banda (24 Gbps) de PLA entre los cuatro puertos, lo que limita el rendimiento de procesamiento global. Si se llenan los puertos 0, 2, 4 y 6 (hasta la versión 3.2.1) o 0, 1, 4 y 5 (a partir de la versión 3.2.2), a los que atiende uno de los ASIC de FabricQ, cuya capacidad de conmutación es de 62 Mpps, también se limita la capacidad de rendimiento de procesamiento.

Así, lo mejor es utilizar los puertos de manera que se obtenga la mayor eficacia de los PLA y los ASIC de FabricQ a fin de poder conseguir un rendimiento óptimo.

SIP-800/SPA

El PLIM SIP-800 ofrece la capacidad de funcionar con tarjetas de interfaz modular, que se denominan Service Port Adapters (SPA). SIP-800 proporciona 6 huecos de SPA con una capacidad de interfaz teórica de 60 Gbps. La capacidad máxima de reenvío de la MSC es de 40 Gbps. Si se llenan todos los puertos disponibles de SIP-800, en función del tipo de SPA, es posible que se produzca un exceso de suscripción y el modelo de QoS pase a ser extremadamente importante para garantizar que el tráfico más importante no se omite sin querer.

Nota: El exceso de suscripción no es compatible con las interfaces POS. Sin embargo, el SPA de POS de 10 Gb se debe colocar correctamente para garantizar que se proporciona el rendimiento de procesamiento correcto. El SPA de Ethernet de 10 Gb sólo es compatible con IOS-XR versión 3.4. Este SPA ofrece capacidades de exceso de suscripción.

A veces, el exceso de suscripción no es una opción y se debe evitar. Para que esto sea posible, sólo se deben utilizar cuatro de los seis huecos. Además, se debe tener cuidado para garantizar que el ancho de banda óptimo de MSC y PLIM esté disponible para cada uno de los cuatro puertos.

Asignación de huecos de SPA

crs-ios-xr-bp7.gif

Como se ha indicado anteriormente, a los puertos físicos los atiende uno de los dos ASIC de FabricQ. La asignación de puertos de ASIC se define estadísticamente y no se puede alterar. Además, el PLIM SIP-800 tiene dos ASIC de PLA. El primer PLA atiende a los puertos 0,1 y 3, el segundo atiende a los puertos 2, 4 y 5.

La capacidad de ancho de banda de un solo PLA de PLIM SIP-800 es de aproximadamente 24 Gbps. La capacidad de conmutación de un solo ASIC de FabricQ es de aproximadamente 62 Mpps.

Si se llenan los puertos 0, 1 y 3, o los puertos 2, 4 y 5, se reparte la capacidad de ancho de banda (24 Gbps) de PLA entre los tres puertos, lo que limita el rendimiento de procesamiento global. Como cada FabricQ atiende a estos grupos de puertos, la velocidad máxima de los paquetes del grupo de puertos es de 62 Mpps. Lo mejor es utilizar los puertos de manera que se obtenga la mayor eficacia de PLA, a fin de poder conseguir un ancho de banda óptimo.

Ubicación recomendada:

 

Nº de hueco de SPA

Nº de hueco de SPA

Nº de hueco de SPA

Nº de hueco de SPA

Opción 1

0

1

4

5

Opción 2

1

2

3

4

Si desea llenar la tarjeta con más de cuatro SPA, es recomendable que siga una de las opciones indicadas anteriormente, que reparten las interfaces entre los dos grupos de puertos (0, 1 y 3, y 2, 4 y 5). A continuación, debe colocar los siguientes módulos de SPA en uno de los puertos abiertos de los grupos de puertos 0, 1 y 3, o bien 2, 4 y 5.

DWDM XENPAK

A partir de la versión 3.2.2, DWDM XENPAK se puede instalar para contar con módulos ópticos ajustables. Los requisitos de enfriamiento de estos módulos XENPAK exigen que haya una ranura vacía entre los módulos instalados. Además, si se instala un único módulo DWDM XENPAK, se pueden utilizar hasta cuatro puertos, aunque los módulos XENPAK no sean dispositivos DWDM. Esto tiene un efecto directo en la asignación de FabricQ > PLA > puerto. Se debe prestar atención a este requisito, tal como se muestra en la siguiente tabla.

Ubicación recomendada:

Nº de puerto óptico

Nº de puerto óptico

Nº de puerto óptico

Nº de puerto óptico

Opción 1 o DWDM XENPAK

0

2

5

7

Opción 2

1

3

4

6

Si instala la versión 3.2.2 o una posterior, o bien la 3.3, evite el cambio de asignación de FabricQ. En estos casos, se puede utilizar un patrón de ubicación más sencillo para los módulos normales y DWDM XENPAK.

Nº de puerto óptico

Nº de puerto óptico

Nº de puerto óptico

Nº de puerto óptico

Opción 1

0

2

4

6

Opción 2

1

3

5

7

Si desea llenar la tarjeta con más de cuatro puertos que no sean DWDM XENPAK, se recomienda que siga una de las opciones indicadas, que reparten los módulos ópticos de interfaz entre los dos grupos de puertos (del 0 al 3 y del 4 al 7). A continuación, debe colocar los siguientes módulos ópticos de interfaz en uno de los puertos abiertos de los grupos de puertos del 0 al 3 o del 4 al 7. Si utiliza el grupo de puertos del 0 al 3 para el módulo óptico de interfaz nº 5, el módulo nº 6 se debe colocar en el grupo de puertos del 4 a 7.

Consulte DWDM XENPAK Modules para obtener más detalles.

Administración de la configuración

En IOS-XR, la configuración se realiza en dos etapas; en la primera etapa, el usuario introduce la configuración. Esta es la etapa en la que CLI comprueba sólo la sintaxis de configuración. La configuración que se introduce en esta etapa sólo la conoce el proceso agente de la configuración, por ejemplo, CLI/XML. Esta configuración no se comprueba por no estar escrita en el servidor sysdb. No se informa a las aplicaciones backend (segundo plano) y no se puede acceder ni obtener ningún tipo de información de la configuración en esta etapa.

En la segunda etapa, el usuario es quien expresamente lleva a cabo la configuración. En esta etapa, la configuración se escribe en el servidor sysdb, las aplicaciones backend (segundo plano) verifican la configuración y sysdb genera las notificaciones. Puede cancelar una sesión de configuración antes de que se lleve a cabo la configuración introducida en la primera etapa. Por ello, no se debe asumir que toda la configuración que se introduzca en la primera etapa se lleve siempre a cabo en la segunda.

Además, la configuración de funcionamiento o ejecución del router la pueden modificar varios usuarios durante la primera y la segunda etapa. Por ello, cualquier prueba del router que ejecute la configuración o el estado de funcionamiento de la primera etapa, puede que no sea válida en la segunda etapa, que es donde realmente se lleva a cabo la configuración.

Sistemas de archivos de configuración

El sistema Configuration File System (CFS) es un conjunto de archivos y directorios que se utiliza para almacenar la configuración del router. El sistema CFS se almacena en el directorio disk0:/config/, que es el medio predeterminado utilizado en RP. Los archivos y directorios de CFS son internos al router y el usuario no debe ni modificarlos ni eliminarlos. Si lo hace, podría provocar pérdidas o daños de configuración y afectar al funcionamiento.

Después de cada procesamiento, el CFS se comprueba con el RP en espera. Así, se facilita la conservación del archivo de configuración del router después de un error.

Durante el inicio del router, se aplica la última configuración activa de la base de datos de configuración almacenada en el CFS. No es necesario que el usuario guarde manualmente la configuración activa después de cada procesamiento de configuración, ya que el router realiza esta operación automáticamente.

No es recomendable realizar cambios en la configuración mientras ésta se aplica durante el inicio. Si no se completa la aplicación de la configuración, aparecerá el siguiente mensaje cuando inicie sesión en el router:

System Configuration Process

The startup configuration for this device is presently loading. This can take a few minutes. You are notified upon completion. Please do not attempt to reconfigure the device until this process is complete. (Proceso de configuración del sistema. En ese momento, se está cargando la configuración de inicio del dispositivo. Esto puede tardar algunos minutos. Recibirá una notificación cuando finalice. No intente volver a configurar el dispositivo hasta que el proceso haya terminado.) En algunos casos aislados, es preferible restaurar la configuración del router a partir de un archivo de configuración ASCII proporcionado por el usuario, en lugar de restaurar la última configuración activa a partir del CFS.

Puede forzar la aplicación de un archivo de configuración mediante:

using the “-a” option with the boot command. This option forces
    the use of the specified file only for this boot.
    
    rommon>boot <image> –a <config-file-path>

    setting the value of “IOX_CONFIG_FILE” boot variable to the
    path of configuration file. This forces the use of the specified file
    for all boots while this variable is set.
    
    rommon>IOX_CONFIG_FILE=<config-file-path>
    rommon>boot <image>

Al restaurar la configuración del router, puede que uno o varios elementos de la configuración no se apliquen. Todas las configuraciones que presenten fallos se guardan en el CFS y se conservan hasta la próxima carga.

Puede acceder a la configuración fallida, solucionar los errores y volver a aplicar dicha configuración.

A continuación, se indican algunos consejos para solucionar una configuración fallida durante el inicio del router.

En IOX, la configuración se puede considerar fallida por tres razones:

  1. Errores de sintaxis: el analizador genera errores de sintaxis, lo que normalmente indica que no hay compatibilidad con los comandos de CLI. Se deben corregir los errores de sintaxis y volver a aplicar la configuración.

  2. Errores semánticos: los componentes backend (segundo plano) generan errores semánticos si el administrador de configuración restaura la configuración durante el inicio del router. Es importante tener en cuenta que cfgmgr no es responsable de asegurarse que la configuración sea aceptada como parte de la configuración en ejecución. Cfgmgr es simplemente un intermediario y sólo informa de los errores semánticos que generan los componentes backend (segundo plano). El análisis y la determinación del motivo de un fallo corresponden al propietario de cada componente backend (segundo plano). Los usuarios pueden ejecutar el comando describe <CLI commands> en el modo de configuración para encontrar fácilmente al propietario del verificador del componente backend (segundo plano). Por ejemplo, si router bgp 217 aparece como una configuración fallida, el comando describe muestra que el verificador del componente es ipv4-bgp.

    RP/0/0/CPU0:router#configure terminal
    RP/0/0/CPU0:router(config)#describe router bgp 217
    The command is defined in bgpv4_cmds.parser
    
    Node 0/0/CPU0 has file bgpv4_cmds.parser for boot package /gsr-os-mbi-3.3.87/mbi12000-rp.vm from gsr-rout
    Package:
        gsr-rout
            gsr-rout V3.3.87[Default]  Routing Package
            Vendor : Cisco Systems
            Desc   : Routing Package
            Build  : Built on Mon Apr  3 16:17:28 UTC 2006
            Source : By ena-view3 in /vws/vpr/mletchwo/cfgmgr_33_bugfix for c2.95.3-p8
            Card(s): RP, DRP, DRPSC
            Restart information:
              Default:
                parallel impacted processes restart
    Component:
        ipv4-bgp V[fwd-33/66]  IPv4 Border Gateway Protocol (BGP)
    
    File: bgpv4_cmds.parser
    
    
    User needs ALL of the following taskids:
    
            bgp (READ WRITE) 
    
    It will take the following actions:
      Create/Set the configuration item:
             Path: gl/ip-bgp/0xd9/gbl/edm/ord_a/running
            Value: 0x1
    Enter the submode:
            bgp
    RP/0/0/CPU0:router(config)#  
  3. Errores de aplicación: la configuración se ha verificado y aceptado correctamente como parte de la configuración en ejecución, pero el componente backend (segundo plano) no puede actualizar su estado de funcionamiento por algún motivo. La configuración se muestra como configuración en ejecución, ya que se ha verificado correctamente, y como configuración fallida, debido al error de funcionamiento backend (segundo plano). El comando describe se puede volver a ejecutar en la CLI fallida para encontrar el propietario de la aplicación del componente.

    • Siga estos pasos para acceder a la configuración fallida y volver a aplicarla durante los operadores de inicio:

      Los operadores de la versión 3.2 pueden utilizar este procedimiento con objeto de volver a aplicar la configuración fallida:

      • Los operadores pueden utilizar el comando show configuration failed startup para acceder a la configuración fallida que se guardó durante el inicio del router.

      • Los operadores deben ejecutar el comando show configuration failed startup noerror | file myfailed.cfg para guardar en un archivo la configuración fallida durante el inicio.

      • Los operadores, en el modo de configuración, pueden utilizar los comandos load/commit para volver a aplicar la configuración fallida:

           RP/0/0/CPU0:router(config)#load myfailed.cfg
           Loading.
           197 bytes parsed in 1 sec (191)bytes/sec
           RP/0/0/CPU0:router(config)#commit
        
    • Los operadores de la versión 3.3 pueden utilizar este procedimiento actualizado:

      Los operadores deben utilizar el comando show configuration failed startup y el comando load configuration failed startup para acceder a cualquier configuración fallida y poder volver a aplicarla.

      RP/0/0/CPU0:router#show configuration failed startup 
      !! CONFIGURATION FAILED DUE TO SYNTAX/AUTHORIZATION ERRORS 
      telnet vrf default ipv4
      server max-servers 5 interface POS0/7/0/3 router static 
      address-family ipv4 unicast
       0.0.0.0/0 172.18.189.1
      
      !! CONFIGURATION FAILED DUE TO SEMANTIC ERRORS 
      router bgp 217 !!%
      Process did not respond to sysmgr !
      RP/0/0/CPU0:router#
      
      RP/0/0/CPU0:router(config)#load configuration failed startup noerror
      Loading.
      263 bytes parsed in 1 sec (259)bytes/sec
      RP/0/0/CPU0:mike3(config-bgp)#show configuration
      Building configuration...
      telnet vrf default ipv4 server max-servers 5 router static 
      address-family ipv4 unicast
        0.0.0.0/0 172.18.189.1
       !
      !
      router bgp 217
      !
      end
      
      RP/0/0/CPU0:router(config-bgp)#commit
      

Vaciado de kernel

De forma predeterminada, IOS-XR produce un vaciado de memoria en el disco duro si falla algún proceso, aunque no lo produce si falla el propio kernel. Tenga en cuenta que en un sistema de chasis múltiple, esta funcionalidad sólo es compatible actualmente con el chasis de tarjeta de línea 0. El resto de chasis será compatible en una versión futura del software.

Se recomienda que el vaciado del kernel esté activado para RP y MSC cuando se utilice esta configuración, en las configuraciones de los modos admin y estándar:

exception kernel memory kernel filepath harddisk:   
exception dump-tftp-route port 0 host-address 10.0.2.1/16 destination 10.0.2.1 next-hop 10.0.2.1 tftp-srvr-addr 10.0.2.1

Configuración del vaciado de kernel

La configuración genera este resultado para un fallo de kernel:

  1. Se produce un fallo en el RP y se escribe un vaciado en el disco duro de ese RP, en el directorio raíz del disco.

  2. Si se produce un fallo en la MSC, se escribe un vaciado en el disco duro de RP0, en el directorio raíz del disco.

Esto no provoca ningún efecto en el tiempo de error de RP, ya que el envío sin pausa (NSF) está configurado para los protocolos de enrutamiento. Puede que pasen algunos minutos más hasta que el RP o la tarjeta de línea del error vuelvan a estar disponibles, mientras se escribe el vaciado de memoria.

A continuación, se muestra un ejemplo de la adición de esta configuración a la configuración de los modos admin y estándar. Tenga en cuenta que la configuración del modo admin requiere que se utilicen DRP.

A continuación, se muestra un ejemplo de configuración de vaciado de kernel:

RP/0/RP0/CPU0:crs1#configure
RP/0/RP0/CPU0:crs1(config)#exception kernel memory kernel filepat$
RP/0/RP0/CPU0:crs1(config)#exception dump-tftp-route port 0 host-$
RP/0/RP0/CPU0:crs1(config)#commit
RP/0/RP0/CPU0:crs1(config)#
RP/0/RP0/CPU0:crs1#admin
RP/0/RP0/CPU0:crs1(admin)#configure
Session                     Line        User      Date                      Lock
00000201-000bb0db-00000000  snmp        hfr-owne  Wed Apr  5 10:14:44 2006 
RP/0/RP0/CPU0:crs1(admin-config)#exception kernel memory kernel f$
RP/0/RP0/CPU0:crs1(admin-config)#exception dump-tftp-route port 0$
RP/0/RP0/CPU0:crs1(admin-config)#commit
RP/0/RP0/CPU0:crs1(admin-config)#
RP/0/RP0/CPU0:crs1(admin)# 

Seguridad

LPTS

Local Packet Transport Services (LPTS) administra paquetes destinados localmente. LPTS está formado por varios componentes diferentes.

  1. El componente principal se denomina proceso árbitro de puertos. Escucha las solicitudes de zócalo de diversos procesos de protocolo, como BGP, IS -IS, y realiza un seguimiento de toda la información de vinculación de esos procesos. Por ejemplo, si un proceso BGP escucha en el número de zócalo 179, el PA obtiene esa información de los procesos BGP y, a continuación, asigna una vinculación a ese proceso en IFIB.

  2. IFIB es otro componente del proceso LPTS. Ayuda a mantener un directorio de dónde escucha un proceso en una vinculación de puerto específica. El proceso árbitro de puertos genera el valor de IFIB y éste se mantiene con el árbitro de puertos. A continuación, genera varios subconjuntos de información.

    El primer subconjunto es una parte de IFIB. Esta parte se puede asociar al protocolo IPv4, etc. Posteriormente, las partes se envían a los administradores de flujo correspondientes, que utilizarán la parte de IFIB para reenviar el paquete al proceso adecuado.

    El segundo subconjunto es previo a IFIB y permite que la LC reenvíe el paquete al proceso correspondiente sólo si existe un proceso, o bien al administrador de flujo adecuado.

  3. Los administradores de flujo ayudan a distribuir mejor los paquetes si la búsqueda no es trivial, como en los procesos múltiples para BGP. Cada administrador de flujo tiene una o varias partes de IFIB y reenvía los paquetes correctamente a los procesos correspondientes asociados a la parte correspondiente de IFIB.

  4. Si no se define ninguna entrada para el puerto de destino, el reenvío puede ir destinado al administrador de flujo o interrumpirse. Un paquete se reenvía sin ningún puerto asociado cuando el puerto correspondiente tiene una política asociada. En ese caso, el administrador de flujo genera una nueva entrada de sesión.

Reenvío de paquetes internos

Existen varios tipos de flujos: flujos de la capa 2 (HDLC, PPP), flujos de la capa 4 ICMP/PING y flujos de enrutamiento.

  1. HDLC/PPP (capa 2): el identificador de protocolos identifica estos paquetes, que se envían directamente a las colas del CPU en el sprayer. Los paquetes de protocolo de la capa 2 obtienen una alta prioridad y la CPU los adquiere (mediante squid) y los procesa. Por lo tanto, las señales de mantenimiento para la capa 2 obtienen respuesta directamente a través de la LC y la CPU. Esto evita la necesidad de acudir al RP en busca de respuestas y está relacionado con el tema de la administración de interfaz distribuida.

  2. Los paquetes ICMP (capa 4) se reciben en la LC y se envían mediante búsqueda a través de IFBI a las colas del CPU en el sprayer. A continuación, estos paquetes se envían a la CPU (mediante squid) y se procesan. La respuesta se envía a través de las colas de salida de sprayer para reenviarse a través de la estructura. Esto se produce en el caso de que otra aplicación también necesite la información (duplicada a través del entramado). Una vez que el paquete ha atravesado la estructura, se envía a la LC de salida correcta, a través del elemento sponge y la cola de control correctos.

  3. Se buscan los flujos de enrutamiento en IFIB y, a continuación, se envían a las listas de espera de modelado de salida (8000 listas de espera), de las que una se reserva para los paquetes de control. Ésta no es una lista de espera de modelado y sólo es atendida cuando está llena (prioridad alta). A continuación, el paquete se envía a través de la estructura en las colas de alta prioridad hacia un conjunto de colas del CPU en sponge (parecidas a las colas de squid en sprayer). Después, el proceso correcto (el administrador de flujos o el proceso real) lo procesan. Se envía una respuesta a través del elemento sponge de la tarjeta de línea de salida hacia el exterior de la tarjeta de línea. El elemento sponge de LC de salida tiene una cola especial para administrar los paquetes de control. Las colas en sponge se dividen en paquetes de alta prioridad, control y baja prioridad teniendo en cuenta los puertos de salida.

  4. PSE tiene un conjunto de reguladores de tráfico configurados para limitar la velocidad de la capa 4, la capa 2 y los paquetes de enrutamiento. Están preconfigurados y cambian para que el usuario pueda configurarlos en el futuro.

Uno de los problemas más habituales de LPTS es el de los paquetes no procesados cuando se intenta hacer ping al router. Los reguladores de tráfico de LPTS normalmente limitan la velocidad de estos paquetes. Éste es el caso para confirmarlo:

RP/0/RP0/CPU0:ss01-crs-1_P1#ping 192.168.3.14 size 8000 count 100                                  
Type escape sequence to abort.
Sending 100, 8000-byte ICMP Echos to 192.168.3.14, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!
!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!
Success rate is 97 percent (97/100), round-trip min/avg/max = 1/2/5 ms
RP/0/RP0/CPU0:ss01-crs-1_P1#show lpts pifib hardware entry statistics location 0/5/CPU0 | excl 0/0
 
* - Vital; L4 - Layer4 Protocol; Intf - Interface;
DestAddr - Destination Fabric Address;
na - Not Applicable or Not Available
 
Local, Remote Address.Port          L4    Intf         DestAddr     Pkts/Drops
----------------------------------- ----- ------------ ------------ --- 
any                                 any   any          Punt       100/3
224.0.0.5 any                       any   PO0/5/1/0    0x3e         4/0
224.0.0.5 any                       any   PO0/5/1/1    0x3e         4/0
<further output elided>

IPsec

En esencia, los paquetes IP son inseguros. IPsec es un método que se utiliza para proteger los paquetes IP. IPsec de CRS-1 se implementa en rutas de reenvío de software, por lo que la sesión de IPsec finaliza en RP/DRP. Se admite una cantidad total de 500 sesiones de IPsec por CRS-1. La cantidad depende de la velocidad del CPU y de la asignación de recursos. No hay limitaciones de software en este aspecto; sólo el tráfico que se origina localmente y que termina localmente en RP, puede ser administrado por IPsec. Como tipo de tráfico, se puede utilizar el modo de transporte IPsec o el de túnel, aunque se prefiere el anterior para una menor sobrecarga de procesamiento de IPsec.

La versión 3.3.0 admite el cifrado de BGP y OSPFv3 a través de IPsec.

Consulte Cisco IOS XR System Security Configuration Guide (Guía de configuración de seguridad del sistema Cisco IOS XR) para obtener más información sobre cómo implementar IPsec.

Nota: IPsec requiere un valor de crypto pie, como hfr-k9sec-p.pie-3.3.1.

Fuera de banda

Acceso a la consola y a AUX

CRS-1 RP/SC tienen un puerto para la consola y para AUX disponible para la administración fuera de banda, así como un puerto Ethernet para la administración fuera de banda a través de IP.

El puerto de la consola y de AUX de cada RP/SCGE (dos por chasis) se puede conectar a un servidor de consola. Esto significa que el sistema de chasis único requiere cuatro puertos de consola y que los sistemas de chasis múltiple requieren 12 puertos, además de dos motores supervisores en Catalyst 6504-E.

La conexión del puerto AUX es importante porque proporciona acceso al kernel de IOS-XR y permite la recuperación del sistema cuando ésta no es posible a través del puerto de la consola. El acceso a través del puerto AUX sólo está disponible para los usuarios definidos localmente en el sistema y siempre que el usuario tenga acceso al nivel del sistema raíz o de soporte de Cisco. Además, el usuario debe tener definida una contraseña secreta.

Acceso a terminal virtual

Para acceder a CRS-1 a través de los puertos vty, se puede utilizar Telnet y shell seguro (SSH). De forma predeterminada, ambos medios están desactivados, por lo que el usuario debe activarlos expresamente.

Nota: IPsec requiere un valor de crypto pie, como hfr-k9sec-p.pie-3.3.1.

Primero genere las claves de RSA y de DSA, según se muestra en este ejemplo para activar SSH:

RP/0/RP1/CPU0:Crs-1#crypto key zeroize dsa
% Found no keys in configuration.
RP/0/RP1/CPU0:Crs-1#crypto key zeroize rsa
% Found no keys in configuration.

RP/0/RP1/CPU0:Crs-1#crypto key generate rsa general-keys
The name for the keys will be: the_default
  Choose the size of the key modulus in the range of 360 to 2048 for your General Purpose Keypair. 
  Choosing a key modulus greater than 512 may take a few minutes.

How many bits in the modulus [1024]: 
Generating RSA keys ...
Done w/ crypto generate keypair
[OK]

RP/0/RP1/CPU0:Crs-1#crypto key generate dsa            
The name for the keys will be: the_default
  Choose the size of your DSA key modulus. Modulus size can be 512, 768, or 1024 bits. Choosing a key modulus
How many bits in the modulus [1024]: 
Generating DSA keys ...
Done w/ crypto generate keypair
[OK] 


!--- VTY access via SSH & telnet can be configured as shown here.

vty-pool default 0 4
ssh server
!
line default
 secret cisco
 users group root-system
 users group cisco-support
 exec-timeout 30 0
transport input telnet ssh
!
!
telnet ipv4 server
Discusiones relacionadas de la comunidad de soporte de Cisco

Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Document ID: 71770