class-default coincide con el tráfico de control?

16

Estoy viendo un problema con BFD en un enlace que está siendo vigilado por egreso donde aparece durante los momentos en que el regulador está maximizado. Los paquetes de BFD no están llegando al otro lado. Me pregunto si los saludos de BFD están sujetos a la policía o si quedan fuera de la policía. Si están sujetos a un regulador, ¿es tan simple como agregar una coincidencia para DSCP CS6 y darle prioridad? A continuación se muestra la configuración:

interface GigabitEthernet1/1
 service-policy output 500meg
end

Router-1#sh policy-map 500meg
  Policy Map 500meg
    Class class-default
     police cir 500000000 bc 31250000 be 31250000
       conform-action transmit
       exceed-action drop
       violate-action drop

— Barro
fuente

1

¿Qué modelo de Cisco estás usando?

— Mike Pennington

@MikePennington 7606 con WS-X6724-SFP

— Barro el

3

Su justificación es correcta (para esta plataforma, no para todas las plataformas). Solo le daría capacidad dedicada a CS6 si garantizara lo que está en CS6 y lo que no. Si no lo garantizo, preferiría usar ACL para que coincida con BFD específicamente. Habiendo dicho eso, 7600 no es una plataforma muy buena para temporizadores BFD agresivos. Rehuiría un intervalo más agresivo que 1s, 3 multiplicador.

— ytti

¿Alguna respuesta te ayudó? Si es así, debe aceptar la respuesta para que la pregunta no siga apareciendo para siempre, buscando una respuesta. Alternativamente, puede proporcionar y aceptar su propia respuesta.

— Ron Maupin

2

@Mud, prácticamente tienes la respuesta a tu pregunta distribuida en varios comentarios, así que simplemente la estoy consolidando aquí en una sola respuesta.

En los 7600s / 6500s puede filtrar BFD (tráfico del plano de control) en el nivel de la interfaz como cualquier otro tráfico (tráfico de tránsito que pasa por el dispositivo).

Cuando aplica una ACL a un puerto en la tarjeta de línea, se aplica a todo el tráfico en esa interfaz. El tráfico que debe ser procesado por el RSP o DFC si los está utilizando debe ser procesado allí, después de que se procese la ACL.

Como regla general, he estado incluyendo tráfico de aviones de control en las políticas de QoS en los últimos tiempos, como las siguientes donde "clase NC" solo coincide con CS6 y CS7:

policy-map QoS-Example
 class NC
  bandwidth percent 2
 !
 class REALTIME
  police rate percent 10
   conform-action transmit
   exceed-action drop
  !
  priority level 1
 !
 class 1
  bandwidth percent 22
 !
 class 2
  bandwidth percent 24
 !
 class 3
  bandwidth percent 12
 ....... and so on

Si escribe una política de CoPP para sus 7600s / 6500s, necesita escribir ACL que coincidan con todos sus tipos relevantes de tráfico de aviones de control. Por lo tanto, también puede hacer coincidir el tráfico BFD haciendo coincidir el tráfico hacia / desde el puerto UDP 3784 (y bloquearlo aún más a su IP de interfaz si es posible).

Como @ytti dijo que debe tener cuidado con los temporizadores BFD en su configuración, si no tiene DFC, su BFD en funcionamiento con la potencia de RSP / CPU. En ese caso, es posible que también desee ver cómo ajustar su comando global "process-max-time" y la programación del proceso "Scheduler allocate xxx xxx".

El mínimo recomendado por Cisco es, bfd interval 100 min_rx 100 multiplier 3pero en algunas cajas de producción sin DFC que estoy ejecutando, lo bfd interval 500 min_rx 500 multiplier 3que ha estado bien, creo que en las cajas con DFC a las que no tengo acceso en este momento, estoy ejecutando lo mismo.

Puede ver estas referencias para obtener más información, que cubre la sintonización de BFD y las ACL para el tráfico del plano de control (tanto CoPP como ACL de interfaz), y también algunos ajustes del plano de control que generalmente son una buena práctica, también el comportamiento de QoS con el tráfico del plano de control:

http://www.cisco.com/c/en/us/td/docs/routers/7600/troubleshoot/guide/7600_Trouble_Shooting.pdf

http://www.cisco.com/c/en/us/td/docs/routers/7600/ios/12-2SR/configuration/guide/swcg/dos.html

http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html

http://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-congestion-management-queueing/18664-rtgupdates.html

— jwbensley
fuente

1

Debido a la naturaleza crítica del paquete de control BFD, no pasa por el mapa de políticas de QoS de salida al salir y se coloca directamente en la cola de salida. Confirmado con TAC.

— Subeh
fuente

-1

De acuerdo con este documento de Cisco "Los usuarios no pueden, por ejemplo, filtrar o aplicar la calidad de servicio (QoS) al paquete BFD transmitido". Así que supongo que esos paquetes obtienen el indicador PAK_PRIORITY .

— Marco Marzetti
fuente

2

PAK_PRIORITY se utiliza para el reenvío acelerado dentro del enrutador / chasis. No es una marca externa. BFD es un plano de datos y debe marcarse / ponerse en cola manualmente para darle un mejor tratamiento.

— Daniel Dib

@Daniel tiene razón. Olvidé mencionar que PAK_PRIORITY es un indicador interno y su comportamiento depende del sistema. En C7600, dichos paquetes marcados se marcan automáticamente con CoS6 y se protegen con cualquier tipo de caída de QoS. Por lo tanto, incluso si puede apostar a que se entregarán los paquetes, si desea un comportamiento de reenvío acelerado, debe definir una cola dedicada.

— Marco Marzetti

@MarcoMarzetti Entonces, para mi propia aclaración: ¿el documento de Cisco se refiere a la entrada de paquetes BFD que no pueden ser QoS'd, y todavía están sujetos a un vigilante de salida?

— Barro

@Mud PAK_PRIORITY es algo interno (es decir, no está marcado). "El software Cisco IOS también tiene un mecanismo interno para otorgar prioridad interna a los datagramas de control importantes a medida que se procesan dentro del enrutador. Este mecanismo se llama PAK_PRIORITY".

— Ryan Foley