El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
Este documento describe los detalles sobre Control Plane Policing (CoPP) en switches Cisco Nexus y su impacto relevante en violaciones de clase no predeterminadas.
Cisco recomienda que comprenda la información básica relativa a Control Plane Policing (CoPP), sus directrices y limitaciones, y la configuración general. Además de la funcionalidad de control de calidad de servicio (QoS) (CIR). Para obtener más información sobre esta función, consulte los documentos aplicables:
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.
El tráfico del plano de control se redirige hacia el módulo supervisor mediante listas de control de acceso (ACL) de redirección programadas para ubicar el tráfico coincidente que pasa a través de dos capas de protección, los limitadores de velocidad de hardware y CoPP. Cualquier interrupción o ataque al módulo supervisor, si no se controla, puede dar lugar a graves interrupciones de la red; por lo tanto, el CoPP está ahí para servir como mecanismo de protección. Si hay inestabilidad en el plano de control, es importante verificar CoPP, porque los patrones de tráfico anormales creados a partir de loops o inundaciones, o los dispositivos no autorizados pueden gravar y evitar que el supervisor procese tráfico legítimo. Tales ataques, que pueden ser perpetrados de forma inadvertida por dispositivos no autorizados o maliciosa por los atacantes, suelen implicar altas tasas de tráfico destinados al módulo supervisor o a la CPU.
Control Plane Policing (CoPP) es una función que protege el plano de control mediante la segregación y clasificación de todos los paquetes recibidos en los puertos en banda (panel frontal) destinados a las direcciones del router o que requieren cualquier intervención del supervisor y la regulación de su tráfico en función de una velocidad de entrada comprometida (CIR). Esta función permite que se aplique un policy map al plano de control. Este mapa de políticas parece una política de calidad de servicio (QoS) normal y se aplica a todo el tráfico que entra en el switch desde un puerto no de gestión. La protección del módulo supervisor mediante la regulación del tráfico permite al switch mitigar las inundaciones de tráfico que superan las velocidades de entrada comprometidas para cada clase descartando los paquetes e impidiendo que el switch se vea saturado e impactando en el rendimiento.
Es importante monitorear continuamente los contadores de CoPP y justificarlos, que es el propósito de este documento. Las violaciones de CoPP, si se dejan sin marcar, pueden impedir que el plano de control procese tráfico real en la clase afectada correspondiente. La configuración de CoPP es un proceso en evolución y en curso que debe responder a los requisitos de infraestructura y de red. Hay tres políticas de sistema predeterminadas para CoPP. De forma predeterminada, Cisco recomienda el uso de la política predeterminada 'strict' como punto de inicio inicial y se utiliza como base para este documento.
La CoPP solo se aplica al tráfico en banda recibido a través de los puertos del panel frontal. El puerto de administración fuera de banda (mgmt0) no está sujeto a CoPP. El hardware del dispositivo Cisco NX-OS realiza CoPP por motor de reenvío. Por lo tanto, elija las velocidades para que el tráfico agregado no sobrecargue el módulo supervisor. Esto es especialmente importante para los switches de fin de fila/modulares, ya que el CIR se aplica al tráfico agregado del tráfico enlazado a la CPU de todos los módulos.
El componente que se describe en este documento se aplica a todos los switches de Data Center Cisco Nexus.
El objetivo de este documento es abordar las violaciones de clase no predeterminadas más comunes y críticas observadas en los switches Nexus.
Para comprender cómo interpretar CoPP, la primera verificación debe ser asegurarse de que se aplica un perfil y comprender si se aplica un perfil predeterminado o un perfil personalizado en el switch.
Nota: Como práctica recomendada, todos los switches Nexus deben tener CoPP habilitado. Si esta función no está activada, puede causar inestabilidad en todo el tráfico del plano de control, ya que diferentes plataformas pueden restringir el tráfico enlazado con Supervisor (SUP). Por ejemplo, si no se habilita CoPP en un Nexus 9000, el tráfico destinado al SUP se limita a 50 pps, lo que hace que el switch sea casi inoperable. CoPP se considera un requisito en las plataformas Nexus 3000 y Nexus 9000.
Si no se habilita CoPP, se puede volver a habilitar o configurar en el switch ejecutando el comando 'setup' o aplicando una de las políticas predeterminadas estándar bajo la opción de configuración: perfil copp [denso|indulgente|moderado|estricto].
Un dispositivo no protegido no clasifica y segrega correctamente el tráfico en clases y, por lo tanto, cualquier comportamiento de denegación de servicio para una función o protocolo específico no se incluye en ese ámbito y puede afectar a todo el plano de control.
Nota: Las políticas de CoPP se implementan mediante redirecciones de clasificación de la memoria direccionable de contenido ternario (TCAM) y se pueden ver directamente en el módulo X de estadísticas de entrada de la lista de acceso interna del sistema show system | b CoPP' o 'show hardware access-list input detail'.
N9K1# show copp status
Last Config Operation: None
Last Config Operation Timestamp: None
Last Config Operation Status: None
Policy-map attached to the control-plane: copp-system-p-policy-strict
copp-system-p-policy-strict is one of the system default profiles, in particular the strict profile.
N9K1# show running-config copp
!Command: show running-config copp
!Running configuration last done at: Tue Apr 26 16:34:10 2022
!Time: Sun May 1 16:30:57 2022
version 10.2(1) Bios:version 05.45
copp profile strict
CoPP clasifica el tráfico en función de las coincidencias que corresponden a las ACL de IP o MAC. Por lo tanto, es importante comprender qué tráfico se clasifica en qué clase.
Las clases, que dependen de la plataforma, pueden variar. Por lo tanto, es importante entender cómo verificar las clases.
Por ejemplo, en la parte superior del rack (TOR) Nexus 9000:
N9K1# show policy-map interface control-plane
Control Plane
Service-policy input: copp-system-p-policy-strict
...
class-map copp-system-p-class-critical (match-any)
match access-group name copp-system-p-acl-bgp
match access-group name copp-system-p-acl-rip
match access-group name copp-system-p-acl-vpc
match access-group name copp-system-p-acl-bgp6
match access-group name copp-system-p-acl-ospf
match access-group name copp-system-p-acl-rip6
match access-group name copp-system-p-acl-eigrp
match access-group name copp-system-p-acl-ospf6
match access-group name copp-system-p-acl-eigrp6
match access-group name copp-system-p-acl-auto-rp
match access-group name copp-system-p-acl-mac-l3-isis
set cos 7
police cir 36000 kbps , bc 1280000 bytes
module 1 :
transmitted 177446058 bytes;
5-minute offered rate 3 bytes/sec
conformed 27 peak-rate bytes/sec
at Sat Apr 23 04:25:27 2022
dropped 0 bytes;
5-min violate rate 0 byte/sec
violated 0 peak-rate byte/sec
...
En este ejemplo, el mapa de clase copp-system-p-class-Critical, abarca el tráfico relacionado con los protocolos de routing, como el protocolo de gateway fronterizo (BGP), Open Shortest Path First (OSPF), el protocolo de router de gateway interior mejorado (EIGRP), e incluye otros protocolos, como vPC.
La convención de nombres de ACL IP o MAC se explica principalmente por sí misma para el protocolo o la función involucrada, con el prefijo copp-system-p-acl-[protocol|feature].
Para ver una clase específica, se puede especificar directamente mientras se ejecuta el comando show. Por ejemplo:
N9K-4# show policy-map interface control-plane class copp-system-p-class-management
Control Plane
Service-policy input: copp-system-p-policy-strict
class-map copp-system-p-class-management (match-any)
match access-group name copp-system-p-acl-ftp
match access-group name copp-system-p-acl-ntp
match access-group name copp-system-p-acl-ssh
match access-group name copp-system-p-acl-http
match access-group name copp-system-p-acl-ntp6
match access-group name copp-system-p-acl-sftp
match access-group name copp-system-p-acl-snmp
match access-group name copp-system-p-acl-ssh6
match access-group name copp-system-p-acl-tftp
match access-group name copp-system-p-acl-https
match access-group name copp-system-p-acl-snmp6
match access-group name copp-system-p-acl-tftp6
match access-group name copp-system-p-acl-radius
match access-group name copp-system-p-acl-tacacs
match access-group name copp-system-p-acl-telnet
match access-group name copp-system-p-acl-radius6
match access-group name copp-system-p-acl-tacacs6
match access-group name copp-system-p-acl-telnet6
set cos 2
police cir 36000 kbps , bc 512000 bytes
module 1 :
transmitted 0 bytes;
5-minute offered rate 0 bytes/sec
conformed 0 peak-rate bytes/sec
dropped 0 bytes;
5-min violate rate 0 byte/sec
violated 0 peak-rate byte/sec
Mientras que los perfiles predeterminados de CoPP se ocultan normalmente como parte de la configuración predeterminada, puede ver la configuración con 'show running-conf copp all':
N9K1# show running-config copp all
!Command: show running-config copp all
!Running configuration last done at: Tue Apr 26 16:34:10 2022
!Time: Sun May 1 16:41:55 2022
version 10.2(1) Bios:version 05.45
control-plane
scale-factor 1.00 module 1
class-map type control-plane match-any copp-system-p-class-critical
match access-group name copp-system-p-acl-bgp
match access-group name copp-system-p-acl-rip
match access-group name copp-system-p-acl-vpc
match access-group name copp-system-p-acl-bgp6
match access-group name copp-system-p-acl-ospf
match access-group name copp-system-p-acl-rip6
match access-group name copp-system-p-acl-eigrp
match access-group name copp-system-p-acl-ospf6
match access-group name copp-system-p-acl-eigrp6
match access-group name copp-system-p-acl-auto-rp
match access-group name copp-system-p-acl-mac-l3-isis
(snip)
...
El mapa de clase copp-system-p-class-Critical, visto anteriormente, hace referencia a varias sentencias de coincidencia que llaman a las ACL del sistema, que de forma predeterminada se ocultan, y hace referencia a la clasificación coincidente. Por ejemplo, para BGP:
N9K1# show running-config aclmgr all | b copp-system-p-acl-bgp
ip access-list copp-system-p-acl-bgp
10 permit tcp any gt 1023 any eq bgp
20 permit tcp any eq bgp any gt 1023
(snip)
Esto significa que cualquier tráfico BGP coincide con esta clase y se clasifica bajo copp-system-p-class-Critical, junto con todos los demás protocolos en esa misma clase.
El Nexus 7000 sigue una estructura de características CoPP muy similar a la del Nexus 9000:
N77-A-Admin# show policy-map interface control-plane
Control Plane
service-policy input copp-system-p-policy-strict
class-map copp-system-p-class-critical (match-any)
match access-group name copp-system-p-acl-bgp
match access-group name copp-system-p-acl-rip
match access-group name copp-system-p-acl-vpc
match access-group name copp-system-p-acl-bgp6
match access-group name copp-system-p-acl-lisp
match access-group name copp-system-p-acl-ospf
match access-group name copp-system-p-acl-rip6
match access-group name copp-system-p-acl-rise
match access-group name copp-system-p-acl-eigrp
match access-group name copp-system-p-acl-lisp6
match access-group name copp-system-p-acl-ospf6
match access-group name copp-system-p-acl-rise6
match access-group name copp-system-p-acl-eigrp6
match access-group name copp-system-p-acl-otv-as
match access-group name copp-system-p-acl-mac-l2pt
match access-group name copp-system-p-acl-mpls-ldp
match access-group name copp-system-p-acl-mpls-rsvp
match access-group name copp-system-p-acl-mac-l3-isis
match access-group name copp-system-p-acl-mac-otv-isis
match access-group name copp-system-p-acl-mac-fabricpath-isis
match protocol mpls router-alert
set cos 7
police cir 36000 kbps bc 250 ms
conform action: transmit
violate action: drop
module 1:
conformed 300763871 bytes,
5-min offered rate 132 bytes/sec
peak rate 125 bytes/sec at Sun May 01 09:50:51 2022
violated 0 bytes,
5-min violate rate 0 bytes/sec
peak rate 0 bytes/sec
module 2:
conformed 4516900216 bytes,
5-min offered rate 1981 bytes/sec
peak rate 1421 bytes/sec at Fri Apr 29 15:40:40 2022
violated 0 bytes,
5-min violate rate 0 bytes/sec
peak rate 0 bytes/sec
module 6:
conformed 0 bytes,
5-min offered rate 0 bytes/sec
peak rate 0 bytes/sec
violated 0 bytes,
5-min violate rate 0 bytes/sec
peak rate 0 bytes/sec
Es importante tener en cuenta que en un Nexus 7000, como se trata de switches modulares, se ve la clase dividida por módulos; sin embargo, el CIR se aplica al agregado de todos los módulos y el CoPP se aplica a todo el chasis. Los resultados y la verificación de CoPP solo se pueden ver desde el contexto de dispositivo virtual (VDC) predeterminado o de administración.
Es especialmente importante verificar la CoPP en un Nexus 7000 si se observan problemas en el plano de control, ya que la inestabilidad en un VDC con tráfico excesivamente ligado a la CPU que causa violaciones de CoPP puede afectar la estabilidad de otros VDC.
En un Nexus 5600 las clases varían. Por lo tanto, para BGP es su propia clase separada:
N5K# show policy-map interface control-plane
Control Plane
(snip)
class-map copp-system-class-bgp (match-any)
match protocol bgp
police cir 9600 kbps , bc 4800000 bytes
conformed 1510660 bytes; action: transmit
violated 0 bytes;
(snip)
En un Nexus 3100, hay 3 clases de protocolo de ruteo, así que para verificar a qué clase pertenece BGP, haga referencia cruzada a la 4 ACL CoPP a la que se hace referencia:
EIGRP es manejado por su propia clase en el Nexus 3100.
N3K-C3172# show policy-map interface control-plane
Control Plane
service-policy input: copp-system-policy
class-map copp-s-routingProto2 (match-any)
match access-group name copp-system-acl-routingproto2
police pps 1300
OutPackets 0
DropPackets 0
class-map copp-s-v6routingProto2 (match-any)
match access-group name copp-system-acl-v6routingProto2
police pps 1300
OutPackets 0
DropPackets 0
class-map copp-s-eigrp (match-any)
match access-group name copp-system-acl-eigrp
match access-group name copp-system-acl-eigrp6
police pps 200
OutPackets 0
DropPackets 0
class-map copp-s-routingProto1 (match-any)
match access-group name copp-system-acl-routingproto1
match access-group name copp-system-acl-v6routingproto1
police pps 1000
OutPackets 0
DropPackets 0
N3K-C3172# show running-config aclmgr
!Command: show running-config aclmgr
!No configuration change since last restart
!Time: Sun May 1 18:14:16 2022
version 9.3(9) Bios:version 5.3.1
ip access-list copp-system-acl-eigrp
10 permit eigrp any 224.0.0.10/32
ipv6 access-list copp-system-acl-eigrp6
10 permit eigrp any ff02::a/128
ip access-list copp-system-acl-routingproto1
10 permit tcp any gt 1024 any eq bgp
20 permit tcp any eq bgp any gt 1024
30 permit udp any 224.0.0.0/24 eq rip
40 permit tcp any gt 1024 any eq 639
50 permit tcp any eq 639 any gt 1024
70 permit ospf any any
80 permit ospf any 224.0.0.5/32
90 permit ospf any 224.0.0.6/32
ip access-list copp-system-acl-routingproto2
10 permit udp any 224.0.0.0/24 eq 1985
20 permit 112 any 224.0.0.0/24
ipv6 access-list copp-system-acl-v6routingProto2
10 permit udp any ff02::66/128 eq 2029
20 permit udp any ff02::fb/128 eq 5353
30 permit 112 any ff02::12/128
ipv6 access-list copp-system-acl-v6routingproto1
10 permit 89 any ff02::5/128
20 permit 89 any ff02::6/128
30 permit udp any ff02::9/128 eq 521
En este caso, el BGP es coincidente con el ACL copp-system-acl-routingproto1 y, por lo tanto, la clase CoPP en la que el BGP cae es copp-s-routingProto1.
CoPP admite estadísticas de QoS para realizar un seguimiento de los contadores agregados de tráfico que confirman o infringen la velocidad de entrada comprometida (CIR) para una clase determinada, para cada módulo.
Cada class-map clasifica el tráfico dirigido a la CPU, en función de la clase a la que corresponde y adjunta un CIR para todos los paquetes que caen dentro de esa clasificación. Como ejemplo, la clase que se relaciona con el tráfico BGP se utiliza como referencia:
En una parte superior del rack (TOR) de Nexus 9000 para copp-system-p-class-Critical:
class-map copp-system-p-class-critical (match-any)
match access-group name copp-system-p-acl-bgp
match access-group name copp-system-p-acl-rip
match access-group name copp-system-p-acl-vpc
match access-group name copp-system-p-acl-bgp6
match access-group name copp-system-p-acl-ospf
match access-group name copp-system-p-acl-rip6
match access-group name copp-system-p-acl-eigrp
match access-group name copp-system-p-acl-ospf6
match access-group name copp-system-p-acl-eigrp6
match access-group name copp-system-p-acl-auto-rp
match access-group name copp-system-p-acl-mac-l3-isis
set cos 7
police cir 36000 kbps , bc 1280000 bytes
module 1 :
transmitted 177446058 bytes;
5-minute offered rate 3 bytes/sec
conformed 27 peak-rate bytes/sec
at Sat Apr 23 04:25:27 2022
dropped 0 bytes;
5-min violate rate 0 byte/sec
violated 0 peak-rate byte/sec
En la sección del mapa de clase, después de las instrucciones match, vemos las acciones que se relacionan con todo el tráfico dentro de la clase. Todo el tráfico clasificado dentro de copp-system-p-class-Critical se establece con una clase de servicio (CoS) de 7, que es el tráfico de mayor prioridad, y esta clase se controla con un CIR de 36000 kbps y una velocidad de ráfaga comprometida de 1280000 bytes. El tráfico que se ajusta a esta política se reenvía a la SUP para que se procese y se suprime cualquier infracción.
set cos 7
police cir 36000 kbps , bc 1280000 bytes
La siguiente sección contiene las estadísticas relacionadas con el módulo, para los switches de la parte superior del rack (TOR), con un solo módulo, el módulo 1 hace referencia al switch.
module 1 :
transmitted 177446058 bytes;
5-minute offered rate 3 bytes/sec
conformed 27 peak-rate bytes/sec
at Sat Apr 23 04:25:27 2022
dropped 0 bytes;
5-min violate rate 0 byte/sec
violated 0 peak-rate byte/sec
Las estadísticas vistas en el resultado son históricas, por lo que esto proporciona una instantánea de las estadísticas actuales en el momento en que se ejecuta el comando.
Hay dos secciones que interpretar aquí: las secciones transmitidas y descartadas:
El punto de datos transmitido realiza un seguimiento de todos los paquetes transmitidos que cumplen con la política. Esta sección es importante ya que proporciona información sobre el tipo de tráfico que el supervisor está procesando.
El valor de velocidad ofrecido de 5 minutos proporciona información sobre la tasa actual.
La velocidad pico y la fecha conformadas proporcionan una instantánea de la velocidad pico más alta por segundos que aún se ajusta a la política y la hora en que se produjo.
Si se ve un nuevo pico, reemplaza este valor y esta fecha.
La parte más importante de las estadísticas es el punto de datos eliminado. Al igual que las estadísticas transmitidas, la sección descartada realiza un seguimiento de los bytes acumulados descartados debido a las violaciones a la velocidad de regulación.
También proporciona, la tasa de violación de los últimos 5 minutos, el pico violado y, si hay un pico, la marca de tiempo de esa violación pico. Y de nuevo, si se ve un nuevo pico, entonces reemplaza este valor y fecha. En otras plataformas, los resultados varían, pero la lógica es muy similar.
Nexus 7000 sigue una estructura idéntica y la verificación es la misma, aunque algunas clases varían ligeramente en las ACL a las que se hace referencia:
class-map copp-system-p-class-critical (match-any)
match access-group name copp-system-p-acl-bgp
match access-group name copp-system-p-acl-rip
match access-group name copp-system-p-acl-vpc
match access-group name copp-system-p-acl-bgp6
match access-group name copp-system-p-acl-lisp
match access-group name copp-system-p-acl-ospf
match access-group name copp-system-p-acl-rip6
match access-group name copp-system-p-acl-rise
match access-group name copp-system-p-acl-eigrp
match access-group name copp-system-p-acl-lisp6
match access-group name copp-system-p-acl-ospf6
match access-group name copp-system-p-acl-rise6
match access-group name copp-system-p-acl-eigrp6
match access-group name copp-system-p-acl-otv-as
match access-group name copp-system-p-acl-mac-l2pt
match access-group name copp-system-p-acl-mpls-ldp
match access-group name copp-system-p-acl-mpls-rsvp
match access-group name copp-system-p-acl-mac-l3-isis
match access-group name copp-system-p-acl-mac-otv-isis
match access-group name copp-system-p-acl-mac-fabricpath-isis
match protocol mpls router-alert
set cos 7
police cir 36000 kbps bc 250 ms
conform action: transmit
violate action: drop
module 1:
conformed 300763871 bytes,
5-min offered rate 132 bytes/sec
peak rate 125 bytes/sec at Sun May 01 09:50:51 2022
violated 0 bytes,
5-min violate rate 0 bytes/sec
peak rate 0 bytes/sec
module 2:
conformed 4516900216 bytes,
5-min offered rate 1981 bytes/sec
peak rate 1421 bytes/sec at Fri Apr 29 15:40:40 2022
violated 0 bytes,
5-min violate rate 0 bytes/sec
peak rate 0 bytes/sec
module 6:
conformed 0 bytes,
5-min offered rate 0 bytes/sec
peak rate 0 bytes/sec
violated 0 bytes,
5-min violate rate 0 bytes/sec
peak rate 0 bytes/sec
En un Nexus 5600:
class-map copp-system-class-bgp (match-any)
match protocol bgp
police cir 9600 kbps , bc 4800000 bytes
conformed 1510660 bytes; action: transmit
violated 0 bytes;
Aunque no proporciona información sobre la velocidad o los picos, sigue proporcionando los bytes agregados conformados y violados.
En un Nexus 3100, se muestra el resultado del plano de control, OutPackets y DropPackets
class-map copp-s-routingProto1 (match-any)
match access-group name copp-system-acl-routingproto1
match access-group name copp-system-acl-v6routingproto1
police pps 1000
OutPackets 8732060
DropPackets 0
OutPackets se refiere a los paquetes conformados, mientras que DropPackets se refiere a las violaciones al CIR. En este escenario, no vemos caídas en la clase asociada.
En un Nexus 3500, el resultado muestra los paquetes coincidentes de hardware y SW:
class-map copp-s-routingProto1 (match-any)
match access-group name copp-system-acl-routingproto1
police pps 900
HW Matched Packets 471425
SW Matched Packets 471425
Los paquetes HW coincidentes hacen referencia a los paquetes que la ACL hace coincidir en HW. Los paquetes coincidentes de SW son los que cumplen con la policía. Cualquier diferencia entre los paquetes HW y SW coincidentes implica una violación.
En este caso, no se ven caídas en los paquetes de clase Routing Protocol-1 (que incluye BGP), ya que los valores coinciden.
Dado que las estadísticas de regulación del plano de control son históricas, es importante determinar si hay violaciones activas en aumento. La forma estándar de realizar esta tarea es comparar dos resultados completos y verificar cualquier diferencia.
Esta tarea se puede realizar manualmente o los switches Nexus proporcionan la herramienta "diff" que puede ayudar a comparar los resultados.
Si bien se puede comparar el resultado completo, no es necesario porque el foco se centra únicamente en las estadísticas caídas. Por lo tanto, el resultado de CoPP se puede filtrar para centrarse solamente en las violaciones.
El comando es el siguiente: show policy-map interface control-plane | egrep class|module|failed|drop | diff -y
Nota: El comando debe ejecutarse dos veces para que el diff pueda comparar el resultado actual con el anterior.
El comando anterior le permite ver el delta entre dos clases y encontrar aumentos de violación.
Nota: Como las estadísticas de CoPP son históricas, otra recomendación es borrar las estadísticas después de ejecutar el comando, para verificar si hay aumentos activos. Para borrar las estadísticas de CoPP, ejecute el comando: 'estadísticas claras de copp'
CoPP es una estructura de regulación simple, ya que se descarta cualquier tráfico de CPU que viole el CIR. No obstante, las consecuencias varían significativamente según el tipo de caídas. Aunque la lógica es la misma, no es lo mismo descartar el tráfico destinado a copp-system-p-class-Critical
class-map copp-system-p-class-critical (match-any)
match access-group name copp-system-p-acl-bgp
match access-group name copp-system-p-acl-rip
match access-group name copp-system-p-acl-vpc
match access-group name copp-system-p-acl-bgp6
match access-group name copp-system-p-acl-ospf
match access-group name copp-system-p-acl-rip6
match access-group name copp-system-p-acl-eigrp
match access-group name copp-system-p-acl-ospf6
match access-group name copp-system-p-acl-eigrp6
match access-group name copp-system-p-acl-auto-rp
match access-group name copp-system-p-acl-mac-l3-isis
set cos 7
police cir 36000 kbps , bc 1280000 bytes
comparado con tráfico descartado destinado a class-map copp-system-p-class-monitor.
class-map copp-system-p-class-monitoring (match-any)
match access-group name copp-system-p-acl-icmp
match access-group name copp-system-p-acl-icmp6
match access-group name copp-system-p-acl-traceroute
set cos 1
police cir 360 kbps , bc 128000 bytes
El primero se ocupa principalmente de los protocolos de routing, el segundo se ocupa del protocolo de mensajes de control de Internet (ICMP), que tiene una de las prioridades más bajas y CIR. La diferencia en CIR es cien veces mayor. Por lo tanto, es importante comprender las clases, los impactos, las verificaciones comunes y las recomendaciones.
Esta clase abarca ICMP para IPv4 e IPv6 y el traceroute de tráfico dirigido al switch en cuestión.
class-map copp-system-p-class-monitoring (match-any)
match access-group name copp-system-p-acl-icmp
match access-group name copp-system-p-acl-icmp6
match access-group name copp-system-p-acl-traceroute
set cos 1
police cir 360 kbps , bc 128000 bytes
-Un concepto erróneo común al solucionar problemas de latencia o pérdida de paquetes está haciendo que el switch pase por sus puertos dentro de banda, que están limitados por la velocidad de CoPP. Como CoPP controla intensamente el ICMP, incluso con un tráfico o una congestión bajos, se puede ver la pérdida de paquetes al hacer ping en las interfaces dentro de la banda directamente si infringen el CIR.
Por ejemplo, al hacer ping en las interfaces conectadas directamente en los puertos enrutados, con una carga útil de paquetes de 500, las caídas se pueden ver periódicamente.
N9K-3# ping 192.168.1.1 count 1000 packet-size 500
...
--- 192.168.1.1 ping statistics ---
1000 packets transmitted, 995 packets received, 0.50% packet loss
round-trip min/avg/max = 0.597/0.693/2.056 ms
En el Nexus, donde se destinaron los paquetes ICMP, vemos que CoPP los descartó cuando se detectó la violación y la CPU estaba protegida:
N9K-4# show policy-map interface control-plane class copp-system-p-class-monitoring
Control Plane
Service-policy input: copp-system-p-policy-strict
class-map copp-system-p-class-monitoring (match-any)
match access-group name copp-system-p-acl-icmp
match access-group name copp-system-p-acl-icmp6
match access-group name copp-system-p-acl-traceroute
set cos 1
police cir 360 kbps , bc 128000 bytes
module 1 :
transmitted 750902 bytes;
5-minute offered rate 13606 bytes/sec
conformed 13606 peak-rate bytes/sec
at Sun May 01 22:49:24 2022
dropped 2950 bytes;
5-min violate rate 53 byte/sec
violated 53 peak-rate byte/sec at Sun May 01 22:49:24 2022
Si se resuelve la latencia o la pérdida de paquetes, se recomienda utilizar los hosts a los que se puede acceder a través del switch por el plano de datos, no destinados al propio switch, que sería el tráfico del plano de control. El tráfico del plano de datos se reenvía/enruta en el nivel de hardware sin la intervención SUP y, por lo tanto, no se controla mediante CoPP, y normalmente no experimenta pérdidas.
-Verificar resultados falsos positivos para la pérdida de paquetes enviando un ping a través del switch a través del plano de datos, no al switch
-Limitar el sistema de supervisión de red (NMS) o las herramientas que utilizan de forma agresiva ICMP el switch para evitar una ráfaga a través de la velocidad de entrada comprometida para la clase. Recuerde que CoPP se aplica a todo el tráfico agregado que cae en la clase.
Como se ve aquí, esta clase abarca diferentes protocolos de administración que se pueden utilizar para la comunicación (SSH, Telnet), las transferencias (SCP, FTP, HTTP, SFTP, TFTP), el reloj (NTP), AAA (Radius/TACACS) y la supervisión (SNMP) para las comunicaciones IPv4 e IPv6.
class-map copp-system-p-class-management (match-any)
match access-group name copp-system-p-acl-ftp
match access-group name copp-system-p-acl-ntp
match access-group name copp-system-p-acl-ssh
match access-group name copp-system-p-acl-http
match access-group name copp-system-p-acl-ntp6
match access-group name copp-system-p-acl-sftp
match access-group name copp-system-p-acl-snmp
match access-group name copp-system-p-acl-ssh6
match access-group name copp-system-p-acl-tftp
match access-group name copp-system-p-acl-https
match access-group name copp-system-p-acl-snmp6
match access-group name copp-system-p-acl-tftp6
match access-group name copp-system-p-acl-radius
match access-group name copp-system-p-acl-tacacs
match access-group name copp-system-p-acl-telnet
match access-group name copp-system-p-acl-radius6
match access-group name copp-system-p-acl-tacacs6
match access-group name copp-system-p-acl-telnet6
set cos 2
police cir 36000 kbps , bc 512000 bytes
Los comportamientos o caídas más comunes asociados a esta clase incluyen:
-Lentitud de CLI percibida cuando se conecta mediante SSH/Telnet. Si hay caídas activas en la clase, las sesiones de comunicación pueden ser lentas y sufrir caídas.
-Transferir archivos con FTP, SCP, SFTP, protocolos TFTP en el switch. El comportamiento más común observado es un intento de transferir imágenes de inicio del sistema/inicio rápido por puertos de administración en banda. Esto puede conducir a tiempos de transferencia más altos y sesiones de transmisión cerradas/terminadas determinadas por el ancho de banda agregado para la clase.
-Problemas de sincronización de NTP, esta clase también es importante porque mitiga los ataques o agentes de NTP desconocidos.
-Los servicios AAA Radius y TACACS también pertenecen a esta clase. Si se percibe el impacto en esta clase, puede afectar a los servicios de autorización y autenticación en el switch para las cuentas de usuario, lo que también puede contribuir a la demora en los comandos CLI.
-SNMP también se controla bajo esta clase. El comportamiento más común visto debido a caídas debido a la clase SNMP se encuentra en los servidores NMS, que realizan caminatas, colecciones masivas o análisis de red. Cuando se produce inestabilidad periódica, generalmente se correlaciona con el programa de recopilación de NMS.
-Si se percibe la lentitud de la CLI, junto con las caídas de esta clase, utilice el acceso a la consola o el acceso fuera de banda de administración (mgmt0).
-Si las imágenes del sistema se deben cargar en el switch, utilice el puerto de administración fuera de banda (mgmt0) o los puertos USB para la transferencia más rápida.
-Si se pierden los paquetes NTP, marque 'show ntp peer-status' y verifique la columna de alcance, ninguna pérdida se traduce a 377.
-Si se observan problemas con los servicios AAA, utilice a los usuarios sólo locales para resolver problemas, hasta que se mitigue el comportamiento
-La mitigación de los problemas de SNMP incluye un comportamiento menos agresivo, la recopilación selectiva o la minimización de los escáneres de red. Examine los tiempos periódicos desde los escáneres hasta los eventos observados en el nivel de CPU.
Esta clase se ocupa específicamente de los paquetes glean. Este tipo de paquete también se gestiona mediante el Limitador de velocidad de hardware (WHRL).
Si la solicitud del protocolo de resolución de direcciones (ARP) para el salto siguiente no se resuelve cuando se reenvían los paquetes IP entrantes en una tarjeta de línea, la tarjeta de línea reenvía los paquetes al módulo supervisor.
El supervisor resuelve la dirección MAC para el salto siguiente y programa el hardware.
class-map copp-system-p-class-l3uc-data (match-any)
match exception glean
set cos 1
Esto ocurre normalmente cuando se utilizan rutas estáticas y el salto siguiente es inalcanzable o no resuelto.
Cuando se envía una solicitud ARP, el software agrega una adyacencia /32 drop en el hardware para evitar que los paquetes se reenvíen a la misma dirección IP de siguiente salto al supervisor. Cuando se resuelve el ARP, la entrada de hardware se actualiza con la dirección MAC correcta. Si la entrada ARP no se resuelve antes de un período de tiempo de espera, la entrada se quita del hardware.
Nota: CoPP y HWRL funcionan en conjunto para garantizar la protección de la CPU. Aunque parece que realizan funciones similares, HWRL se produce primero. La implementación se basa en dónde se implementa la función específica en los motores de reenvío en el ASIC. Este enfoque serial permite granularidad y protecciones multicapa que califican todos los paquetes enlazados a la CPU.
El HWRL se realiza por instancia/motor de reenvío en el módulo y se puede ver con el comando 'show hardware rate-limiter'. HWRL está fuera del alcance de este documento técnico.
show hardware rate-limiter
Units for Config: kilo bits per second
Allowed, Dropped & Total: aggregated bytes since last clear counters
Module: 1
R-L Class Config Allowed Dropped Total
+----------------+----------+--------------------+--------------------+--------------------+
L3 glean 100 0 0 0
L3 mcast loc-grp 3000 0 0 0
access-list-log 100 0 0 0
bfd 10000 0 0 0
fex 12000 0 0 0
span 50 0 0 0
sflow 40000 0 0 0
vxlan-oam 1000 0 0 0
100M-ethports 10000 0 0 0
span-egress disabled 0 0 0
dot1x 3000 0 0 0
mpls-oam 300 0 0 0
netflow 120000 0 0 0
ucs-mgmt 12000 0 0 0
-El tráfico del plano de datos se envía al supervisor como una violación, ya que no se puede procesar en el hardware y, por lo tanto, crea presión en la CPU.
-La resolución común para este asunto de minimizar las caídas brillantes es asegurar que el salto siguiente sea alcanzable, y habilitar la regulación de brillo mediante el comando de configuración: 'acelerador ip glean del hardware'
-En Nexus 7000 8.4(2) también introdujo el soporte de filtros de floración para adyacencias de glean para los módulos M3 y F4. Consulte: https://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/nx-os/unicast/configuration/guide/b-7k-Cisco-Nexus-7000-Series-NX-OS-Unicast-Routing-Configuration-Guide-Release/n7k_unicast_config_ipv4.html#concept_4B4BF5FE17DE443EAAD710690FE670EB
-Revise cualquier configuración de ruta estática que utilice direcciones de siguiente salto inalcanzables o utilice protocolos de ruteo dinámicos que eliminen dichas rutas del RIB dinámicamente
Esta clase hace referencia a los protocolos de plano de control más críticos desde una perspectiva de L3, que incluyen protocolos de routing para IPv4 e IPv6 (RIP, OSPF, EIGRP, BGP), RP automático, canal de puerto virtual (vPC) y l2pt e IS-IS.
class-map copp-system-p-class-critical (match-any)
match access-group name copp-system-p-acl-bgp
match access-group name copp-system-p-acl-rip
match access-group name copp-system-p-acl-vpc
match access-group name copp-system-p-acl-bgp6
match access-group name copp-system-p-acl-ospf
match access-group name copp-system-p-acl-rip6
match access-group name copp-system-p-acl-eigrp
match access-group name copp-system-p-acl-ospf6
match access-group name copp-system-p-acl-eigrp6
match access-group name copp-system-p-acl-auto-rp
match access-group name copp-system-p-acl-mac-l2pt
match access-group name copp-system-p-acl-mac-l3-isis
set cos 7
police cir 36000 kbps , bc 1280000 bytes
Los descartes en la inestabilidad de la transferencia copp-system-p-class-key a los protocolos de ruteo, que pueden incluir fallas de caída o convergencia de adyacencias, o propagación de actualización/NLRI.
Las caídas de políticas más comunes en esta clase pueden estar relacionadas con dispositivos no autorizados en la red que actúan de forma anormal (debido a una configuración incorrecta o a fallos) o a la escalabilidad.
-Si no se detectan anomalías, como un dispositivo no autorizado o la inestabilidad L2 que causa la reconvergencia continua de los protocolos de capa superior, se puede requerir una configuración personalizada de CoPP o una clase más indulgente para acomodar la escala.
-Consulte la guía de configuración de CoPP para ver cómo configurar un perfil CoPP personalizado a partir de un perfil predeterminado que existe actualmente.
https://www.cisco.com/c/en/us/td/docs/dcn/nx-os/nexus9000/102x/configuration/Security/cisco-nexus-9000-nx-os-security-configuration-guide-102x/m-configuring-copp.html#task_E3D04369F59F471885BC5E8CD24337CA
Esta clase se relaciona con los protocolos de redundancia de primer salto (FHRP), incluidos HSRP, VRRP y también LLDP
class-map copp-system-p-class-important (match-any)
match access-group name copp-system-p-acl-hsrp
match access-group name copp-system-p-acl-vrrp
match access-group name copp-system-p-acl-hsrp6
match access-group name copp-system-p-acl-vrrp6
match access-group name copp-system-p-acl-mac-lldp
set cos 6
police cir 2500 kbps , bc 1280000 bytes
El comportamiento más común que se ha observado aquí, que conduce a caídas, son los problemas de inestabilidad de capa 2, que lleva a que los dispositivos se transformen en escenarios de estado activo (cerebro dividido), temporizadores agresivos, configuraciones incorrectas o escalabilidad.
-Asegúrese de que para FHRP, los grupos estén correctamente configurados y que los roles activo/en espera o primario/secundario se negocien correctamente y que no haya inestabilidades en el estado.
-Verifique los problemas de convergencia en L2 o los problemas con propagación multicast para el dominio L2.
La clase no controlada L2 se refiere a todos los protocolos críticos de Capa 2 que son el trabajo de base para todos los protocolos de capa superior y, por lo tanto, se consideran casi sin vigilancia con la CIR y prioridad más alta.
Esta clase gestiona de forma eficaz el protocolo de árbol de extensión (STP), el protocolo de control de agregación de enlaces (LACP) y el servicio Cisco Fabric Service over Ethernet (CFSoE)
class-map copp-system-p-class-l2-unpoliced (match-any)
match access-group name copp-system-p-acl-mac-stp
match access-group name copp-system-p-acl-mac-lacp
match access-group name copp-system-p-acl-mac-cfsoe
match access-group name copp-system-p-acl-mac-sdp-srp
match access-group name copp-system-p-acl-mac-l2-tunnel
match access-group name copp-system-p-acl-mac-cdp-udld-vtp
set cos 7
police cir 50 mbps , bc 8192000 bytes
Esta clase tiene una CIR de policía de 50 Mbps, la más alta entre todas las clases, junto con la mayor absorción de velocidad de ráfaga.
Las caídas de esta clase pueden provocar inestabilidad global, ya que todos los protocolos de capa superior y las comunicaciones en los planos de datos, control y gestión dependen de una estabilidad de capa 2 subyacente.
Los problemas con las violaciones de STP pueden causar problemas de convergencia de TCN y STP, que incluyen disputas de STP, vaciados de MAC, movimientos y comportamientos de aprendizaje inhabilitados, que causan problemas de accesibilidad y pueden causar loops de tráfico que desestabilizan la red.
Esta clase también hace referencia al LACP y, por lo tanto, maneja todos los paquetes EtherType asociados con 0x8809, que incluyen todos los LACPDU usados para mantener el estado de los links de canal de puerto. La inestabilidad en esta clase puede hacer que los canales de puerto se detengan si se descartan los LACPDU.
El servicio Cisco Fabric Service over Ethernet (CSFoE) pertenece a esta clase y se utiliza para comunicar los estados de control de aplicaciones fundamentales entre los switches Nexus y, por lo tanto, es imprescindible para la estabilidad.
Lo mismo se aplica a otros protocolos dentro de esta clase, que incluye CDP, UDLD y VTP.
-El comportamiento más común se relaciona con la inestabilidad de Ethernet L2. Asegúrese de que el STP esté correctamente diseñado de manera determinista con las mejoras de las funciones relevantes en juego para minimizar el impacto de la reconvergencia o de los dispositivos no autorizados en la red. Asegúrese de que el tipo de puerto STP adecuado esté configurado para todos los dispositivos host finales que no participan en la extensión L2 estén configurados como puertos troncales de borde/borde para minimizar los TCN.
-Utilice mejoras de STP, como BPDUguard, Loopguard, BPDUfilter, RootGuard, si procede, para limitar el alcance de una falla o problemas con dispositivos no autorizados o de configuración incorrecta en la red.
-Compruebe si hay comportamientos de movimiento de MAC que puedan conducir a que el aprendizaje de MAC se deshabilite y se purgue. Consulte: https://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/nx-os-software/213906-nexus-9000-mac-move-troubleshooting-and.html
Esta clase hace referencia a los paquetes de multidifusión independiente de protocolo (PIM) del plano de control utilizados para el establecimiento y el control de árboles compartidos de multidifusión enrutados a través de todos los dispositivos habilitados para PIM en la ruta del plano de datos, incluidos el router de primer salto (FHR), el router de último salto (LHR), los routers de saltos intermedios (IHR) y los puntos de vales de renovación (RP). Los paquetes clasificados dentro de esta clase incluyen el registro de PIM para orígenes, las uniones de PIM para receptores tanto para IPv4 como para IPv6, en general cualquier tráfico destinado a PIM (224.0.0.13) y el protocolo de detección de fuente multidifusión (MSDP). Tenga en cuenta que hay varias clases adicionales, que se ocupan de porciones muy específicas de la funcionalidad de multidifusión o RP que son manejadas por diferentes clases.
class-map copp-system-p-class-multicast-router (match-any)
match access-group name copp-system-p-acl-pim
match access-group name copp-system-p-acl-msdp
match access-group name copp-system-p-acl-pim6
match access-group name copp-system-p-acl-pim-reg
match access-group name copp-system-p-acl-pim6-reg
match access-group name copp-system-p-acl-pim-mdt-join
match exception mvpn
set cos 6
police cir 2600 kbps , bc 128000 bytes
El impacto principal en las caídas que se relacionan con esta clase se asocia con problemas que se comunican con los orígenes multicast mediante el registro PIM hacia los RPs o las uniones PIM no procesadas correctamente, lo que desestabilizaría los árboles de trayectoria compartida o más corta hacia los orígenes del flujo multicast o hacia los RPs. El comportamiento puede incluir la lista de interfaces salientes (OIL) que no se ha rellenado correctamente debido a la falta de uniones, o (S, G) o (*, G) que no se ven de forma uniforme en todo el entorno. También pueden surgir problemas entre los dominios de ruteo multicast que dependen de MSDP para la interconexión.
-El comportamiento más común para los problemas relacionados con el control de PIM se refiere a problemas de escala o comportamientos poco fiables. Uno de los comportamientos más comunes se observa debido a la implementación en UPnP, que también puede causar problemas de agotamiento de memoria. Esto se puede solucionar mediante filtros y un alcance reducido de los dispositivos no autorizados. Para obtener detalles sobre cómo mitigar y filtrar los paquetes de control multicast según la función de red del dispositivo, consulte:
Configuración del filtrado multidifusión en Nexus 7K/N9K - Cisco
Esta clase hace referencia a Multicast Listener Discovery (MLD), específicamente a los tipos de paquetes MLD query, report, Reducy MLDv2. MLD es un protocolo IPv6 que utiliza un host para solicitar datos de multidifusión para un grupo determinado. Con la información obtenida a través de MLD, el software mantiene una lista de membresías de canal o grupo multicast por interfaz. Los dispositivos que reciben paquetes MLD envían los datos multicast que reciben para los grupos solicitados o canales fuera del segmento de red de los receptores conocidos. MLDv1 se deriva de IGMPv2 y MLDv2 se deriva de IGMPv3. IGMP utiliza tipos de mensajes de protocolo IP 2, mientras que MLD utiliza tipos de mensajes de protocolo IP 58, que es un subconjunto de los mensajes ICMPv6.
class-map copp-system-p-class-multicast-host (match-any)
match access-group name copp-system-p-acl-mld
set cos 1
police cir 1000 kbps , bc 128000 bytes
Las caídas en esta clase se traducen en problemas en las comunicaciones multicast IPv6 locales de link, lo que puede hacer que los informes de listener de los receptores o las respuestas a las consultas generales se descarten, lo que evita la detección de grupos multicast que los hosts desean recibir. Esto puede afectar al mecanismo de snooping y no reenviar correctamente el tráfico a través de las interfaces esperadas que solicitaron el tráfico.
-Como el tráfico MLD es significativo en un nivel de link local para IPv6, si se ven caídas en esta clase, las causas más comunes de comportamiento se relacionan con la escala, la inestabilidad L2 o los dispositivos no autorizados.
Estas clases hacen referencia al tráfico que coincide con una redirección de excepción multicast hacia el SUP. En este caso, estas clases manejan dos condiciones. La primera es la falla de Reenvío de Trayectoria Inversa (RPF) y la segunda es la pérdida de destino. Destination Miss se refiere a los paquetes multicast donde la búsqueda en hardware para la tabla de reenvío multicast de la Capa 3 falla y, por lo tanto, el paquete de datos se envía a la CPU. Estos paquetes se utilizan a veces para activar/instalar el plano de control multicast y agregar las entradas de las tablas de reenvío de hardware, según el tráfico del plano de datos. Los paquetes multicast del plano de datos que violan el RPF también coincidirían con esta excepción y se clasificarían como una violación.
class-map copp-system-p-class-l3mc-data (match-any)
match exception multicast rpf-failure
match exception multicast dest-miss
set cos 1
police cir 2400 kbps , bc 32000 bytes
class-map copp-system-p-class-l3mcv6-data (match-any)
match exception multicast ipv6-rpf-failure
match exception multicast ipv6-dest-miss
set cos 1
police cir 2400 kbps , bc 32000 bytes
Las fallas de RPF y las pérdidas de destino implican un problema de diseño o configuración relacionado con cómo fluye el tráfico a través del router multicast. Las pérdidas de destino son comunes en la creación del estado, las caídas pueden llevar a la programación y creación de (*, G), (S, G) que fallan.
-Realice cambios en el diseño de RIB de unidifusión básica o agregue rutas multicast estáticas para dirigir el tráfico a través de una interfaz particular, en el caso de fallas de RPF.
- Consulte https://www.cisco.com/c/en/us/support/docs/ip/ip-multicast/16450-mcastguide0.html#anc5
Esta clase hace referencia a todos los mensajes IGMP, para todas las versiones que se utilizan para solicitar datos de multidifusión para un grupo determinado, y que la funcionalidad de indagación IGMP utiliza para mantener los grupos y la lista de interfaz saliente (OIL) relevante que reenvía el tráfico a los receptores interesados en la capa 2. Los mensajes IGMP son localmente significativos porque no atraviesan un límite de Capa 3, ya que su tiempo de vida (TTL) debe ser 1, como se documenta en RFC2236 (https://datatracker.ietf.org/doc/html/rfc2236). Los paquetes IGMP manejados por esta clase incluyen todas las consultas de membresía (generales o específicas de origen/grupo), junto con la membresía y dejan los informes de los receptores.
class-map copp-system-p-class-normal-igmp (match-any)
match access-group name copp-system-p-acl-igmp
set cos 3
police cir 3000 kbps , bc 64000 bytes
Los descartes en esta clase se traducirían en problemas en todos los niveles de una comunicación multicast entre el origen y el receptor, dependiendo del tipo de mensaje IGMP descartado debido a la violación. Si se pierden los informes de pertenencia de los receptores, el router no conoce los dispositivos interesados en el tráfico y, por lo tanto, no incluye la interfaz/VLAN en su lista de interfaz saliente relevante. Si este dispositivo es también el solicitante o el router designado, no activa los mensajes de unión PIM relevantes hacia el RP si el origen está más allá del dominio de Capa 2 local, por lo tanto nunca establece el plano de datos a través del árbol multicast hasta el receptor o RP. Si se pierde el informe de ausencia, el receptor puede continuar recibiendo tráfico no deseado. Esto también puede afectar todas las consultas IGMP relevantes activadas por el consultor y la comunicación entre los routers multicast en un dominio.
-Los comportamientos más comunes asociados con las caídas de IGMP se relacionan con la inestabilidad de L2, problemas con temporizadores o escalas.
Esta clase hace referencia al tráfico que coincide con el tráfico ARP estándar y también incluye el tráfico asociado con 802.1X, utilizado para el control de acceso a la red basado en puertos. Esta es una de las clases más comunes que encuentra violaciones cuando el ARP solicita, el ARP Gratuito, los paquetes ARP Inverso se transmiten y propagan a través de todo el dominio de Capa 2. Es importante recordar que los paquetes ARP no son paquetes IP, estos paquetes no contienen un encabezado L3, por lo que la decisión se toma únicamente en el alcance de los encabezados L2. Si un router se configura con una interfaz IP asociada a esa subred, como una interfaz virtual de switch (SVI), el router envía los paquetes ARP a la SUP para que se procesen, ya que están destinados a la dirección de difusión de hardware. Cualquier tormenta de broadcast, loop de Capa 2 (debido a STP o inestabilidad), o un dispositivo de ruteo en la red, puede conducir a una tormenta ARP que provoca un aumento significativo de las violaciones.
class-map copp-system-p-class-normal (match-any)
match access-group name copp-system-p-acl-mac-dot1x
match protocol arp
set cos 1
police cir 1400 kbps , bc 32000 bytes
El impacto de las violaciones en esta clase depende en gran medida de la duración de los eventos y del rol del switch en el entorno. Las caídas en esta clase implican que los paquetes ARP están siendo descartados y, por lo tanto, no procesados por el motor SUP que puede conducir a dos comportamientos principales causados por resoluciones ARP incompletas.
Desde la perspectiva del host final, los dispositivos de la red no pueden resolver o completar la resolución de direcciones con el switch. Si este dispositivo actúa como el gateway predeterminado para el segmento, puede provocar que los dispositivos no puedan resolver su gateway y, por lo tanto, no puedan rutear fuera de su segmento Ethernet L2 (VLAN). Los dispositivos todavía pueden comunicarse en el segmento local si pueden completar la resolución ARP para otros hosts finales en el segmento local.
Desde la perspectiva del switch, si la tormenta y las violaciones son prevalentes, también puede conducir a que el switch no pueda completar el proceso para la solicitud ARP que generó. Estas solicitudes se generan normalmente para las resoluciones de subred de salto siguiente o directamente conectadas. Aunque las respuestas ARP son de naturaleza unicast, ya que se dirigen a la MAC propiedad del switch, se clasifican en esta misma clase, ya que siguen siendo paquetes ARP. Esto se traduce en problemas de disponibilidad porque el switch no puede procesar correctamente el tráfico si el salto siguiente no se resuelve, y puede conducir a problemas con la reescritura del encabezado de Capa 2, si el administrador de adyacencia no tiene una entrada para el host.
El impacto también depende del alcance del problema fundamental que desencadenó la violación ARP. Por ejemplo, en una tormenta de difusión, los hosts y el switch continúan en ARP para intentar resolver la adyacencia, lo que puede llevar a tráfico de broadcast adicional en la red, y como los paquetes ARP son de Capa 2, no hay tiempo de vida de Capa 3 (TTL) para romper un loop L2 y, por lo tanto, siguen en loop, y crecen exponencialmente a través de la red hasta que se rompe el loop.
-Resolver cualquier inestabilidad L2 fundamental que pueda causar tormentas ARP en el entorno, como STP, flaps o dispositivos no autorizados. Rompa esos loops según sea necesario, por cualquier método que desee para abrir la ruta de acceso del link.
-El control de tormentas también se puede utilizar para mitigar una tormenta ARP. Si el control de tormentas no está habilitado, verifique las estadísticas del contador en las interfaces para verificar el porcentaje de tráfico de broadcast visto en las interfaces en relación con el tráfico total que pasa a través de la interfaz.
-Si no hay tormenta, pero todavía se observan caídas constantes en el entorno, verifique el tráfico SUP para identificar cualquier dispositivo no autorizado, enviando constantemente paquetes ARP en la red, lo que puede estar afectando al tráfico legítimo.
-Los aumentos se pueden ver dependiendo del número de hosts en la red y del rol del switch en el entorno, el ARP está diseñado para reintentar, resolver y actualizar las entradas y, por lo tanto, se espera que vea el tráfico ARP en todo momento. Si solo se observan caídas esporádicas, pueden ser transitorias dependiendo de la carga de la red y no se percibe ningún impacto. Pero es importante supervisar y conocer la red para identificar y diferenciar adecuadamente una situación esperada de una situación anormal.
Esta clase hace referencia al tráfico asociado con la detección/anuncio de vecino IPv6 y los paquetes de solicitud y anuncio del router que utilizan mensajes ICMP para determinar las direcciones de capa de link locales de los vecinos, y se utiliza para la disponibilidad y el seguimiento de los dispositivos vecinos.
class-map copp-system-p-class-ndp (match-any)
match access-group name copp-system-p-acl-ndp
set cos 6
police cir 1400 kbps , bc 32000 bytes
Las violaciones en esta clase pueden impedir la comunicación IPv6 entre dispositivos vecinos, ya que estos paquetes se utilizan para facilitar la detección dinámica o la información de capa de link/local entre hosts y routers en el link local. Una ruptura de esta comunicación también puede causar problemas con la disponibilidad más allá o a través del link local asociado. Si hay problemas de comunicación entre los vecinos IPv6, asegúrese de que no haya caídas en esta clase.
-Examine cualquier comportamiento ICMP anormal de los dispositivos vecinos, particularmente aquellos que se relacionan con la detección de vecinos y/o la detección del router
-Asegúrese de que todos los valores esperados del temporizador y del intervalo para los mensajes periódicos sean consistentes en todo el entorno y se cumplan, por ejemplo, para los mensajes de anuncio del router (mensajes RA).
Esta clase hace referencia al tráfico asociado al protocolo de arranque (cliente/servidor BOOTP), comúnmente conocido como paquetes de protocolo de control de host dinámico (DHCP) en el mismo segmento Ethernet local para IPv4 e IPv6. Esto se relaciona específicamente con la comunicación de tráfico que se origina desde cualquier cliente de arranque o destinado a cualquier servidor BOOTP, a través de la detección, oferta, solicitud y reconocimiento (DORA) completa del intercambio de paquetes, y también incluye la transacción cliente/servidor DHCPv6 a través de los puertos UDP 546/547.
class-map copp-system-p-class-normal-dhcp (match-any)
match access-group name copp-system-p-acl-dhcp
match access-group name copp-system-p-acl-dhcp6
set cos 1
police cir 1300 kbps , bc 32000 bytes
Las violaciones de esta clase pueden conducir a que los hosts finales no puedan adquirir correctamente una IP del servidor DHCP y, por lo tanto, vuelvan al intervalo de direcciones IP privadas (APIPA) automáticas 169.254.0.0/16. Estas violaciones pueden ocurrir en entornos en los que los dispositivos intentan arrancar simultáneamente y, por lo tanto, van más allá del CIR asociado a la clase.
-Verifique con capturas, en los hosts y en el lado del servidor DHCP toda la transacción DORA. Si el switch es parte de esta comunicación, también es importante verificar los paquetes procesados o impulsados a la CPU y verificar las estadísticas en el switch: 'show ip dhcp global statistics' y redirecciones: 'show system internal access-list sup-redirect-stats module 1 | grep -i dhcp'.
Esta clase hace referencia al tráfico asociado a la funcionalidad de relé DHCP tanto para IPv4 como para IPv6, dirigido a los servidores DHCP configurados bajo la retransmisión. Esto se relaciona específicamente con la comunicación de tráfico que se origina desde cualquier servidor BOOTP o se dirige a cualquier cliente BOOTP a través de todo el intercambio de paquetes DORA, e incluye también la transacción cliente/servidor DHCPv6 a través de los puertos UDP 546/547.
class-map copp-system-p-class-normal-dhcp-relay-response (match-any)
match access-group name copp-system-p-acl-dhcp-relay-response
match access-group name copp-system-p-acl-dhcp6-relay-response
set cos 1
police cir 1500 kbps , bc 64000 bytes
Las violaciones para esta clase tienen el mismo impacto que las violaciones para la clase copp-system-p-class-normal-dhcp, porque ambas son partes de la misma transacción. Esta clase se centra principalmente en las comunicaciones de respuesta de los servidores de agente relay. El Nexus no actúa como el servidor DHCP, está diseñado sólo para actuar como agente relay.
Aquí se aplican las mismas recomendaciones que el DHCP normal de clase. Como la función del Nexus es solamente actuar como agente relay, en el SUP usted espera ver toda la transacción entre el host y el switch actuando como relay, y el switch y los servidores configuran.
Asegúrese de que no haya dispositivos sospechosos, como servidores DHCP inesperados que se ejecuten en la red que puedan responder al alcance, o dispositivos atascados en un loop que inunde la red con paquetes DHCP Discover. Los comandos pueden realizar verificaciones adicionales: 'show ip dhcp relay' y 'show ip dhcp relay statistics'.
Esta clase hace referencia al tráfico de flujo NAT del switch de software. Cuando se crea una nueva traducción dinámica, el flujo se reenvía por software hasta que la traducción se programa en hardware, y luego es controlada por CoPP para limitar el tráfico dirigido al supervisor mientras la entrada está instalada en hardware.
class-map copp-system-p-class-nat-flow (match-any)
match exception nat-flow
set cos 7
police cir 800 kbps , bc 64000 bytes
Las caídas de esta clase se producen normalmente cuando se instala una alta tasa de nuevas traducciones dinámicas y flujos en el hardware. El impacto se relaciona con los paquetes conmutados de software que se descartan y no se entregan al host final, lo que puede conducir a pérdidas y retransmisiones. Una vez instalada la entrada en el hardware, no se impulsa más tráfico al supervisor.
-Verifique las pautas y limitaciones de la NAT dinámica en la plataforma relevante. Existen limitaciones conocidas que se documentan en las plataformas, como el 3548, en el que la traducción puede tardar unos segundos. Consulte: https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus3548/sw/93x/interfaces/configuration/guide/b-cisco-nexus-3500-nx-os-interfaces-configuration-guide-93x/b-cisco-nexus-3500-nx-os-interfaces-configuration-guide-93x_chapter_0110.html#id_35947
Esta clase hace referencia a los paquetes de excepción asociados con la opción IP y los paquetes IP ICMP inalcanzables. Si una dirección de destino no está presente en la base de información de reenvío (FIB) y da lugar a una pérdida, el SUP envía un paquete ICMP inalcanzable al remitente. Los paquetes con opciones IP activadas también pertenecen a esta clase. Consulte el documento IANA para obtener detalles sobre las opciones IP: https://www.iana.org/assignments/ip-parameters/ip-parameters.xhtml#ip-parameters-1
class-map copp-system-p-class-exception (match-any)
match exception ip option
match exception ip icmp unreachable
match exception ipv6 option
match exception ipv6 icmp unreachable
set cos 1
police cir 150 kbps , bc 32000 bytes
Esta clase está fuertemente controlada, y las caídas en esta clase no son indicativas de una falla, sino de un mecanismo de protección para limitar el alcance de los paquetes ICMP inalcanzables y de opciones IP.
-Verifique si hay algún flujo de tráfico visto o dirigido a la CPU para destinos que no están en la FIB.
Esta clase hace referencia al tráfico asociado con el protocolo de tiempo de precisión (PTP), utilizado para la sincronización horaria. Esto incluye tráfico multicast para el rango reservado 224.0.1.129/32, tráfico unicast en el puerto UDP 319/320 y Ethetype 0X88F7.
class-map copp-system-p-class-redirect (match-any)
match access-group name copp-system-p-acl-ptp
match access-group name copp-system-p-acl-ptp-l2
match access-group name copp-system-p-acl-ptp-uc
set cos 1
police cir 280 kbps , bc 32000 bytes
Las caídas de esta clase pueden provocar problemas en dispositivos que no se han sincronizado correctamente o que no han establecido la jerarquía adecuada.
-Garantizar la estabilidad de los relojes y que estén configurados correctamente. Asegúrese de que el dispositivo PTP esté configurado para el modo PTP de multidifusión o unidifusión, pero no ambos al mismo tiempo. Esto también se documenta según las pautas y la limitación, y puede llevar el tráfico más allá de la velocidad de entrada comprometida.
-Revise el diseño y la configuración del reloj de frontera y de todos los dispositivos PTP en el entorno. Asegúrese de que se siguen todas las directrices y limitaciones por plataforma porque varían.
Esta clase hace referencia al tráfico asociado con las operaciones del agente de OpenFlow y la conexión TCP correspondiente entre el controlador y el agente.
class-map copp-system-p-class-openflow (match-any)
match access-group name copp-system-p-acl-openflow
set cos 5
police cir 1000 kbps , bc 32000 bytes
Las caídas de esta clase pueden provocar problemas en los agentes que no reciben y procesan correctamente las instrucciones del controlador para gestionar el plano de reenvío de la red
-Asegúrese de que no se ve tráfico duplicado en la red o en ningún dispositivo que obstaculice la comunicación entre el controlador y los agentes.
-Verifique que la red L2 no tenga inestabilidad (STP, loops).
Los primeros pasos para solucionar las violaciones de CoPP son determinar:
- Impacto y alcance de la cuestión
-Comprender el flujo de tráfico a través del entorno y el rol del switch en la comunicación afectada
-Determine si se sospechan violaciones en la clase asociada e itere según sea necesario.
Por ejemplo, se ha detectado el comportamiento enumerado:
-Los dispositivos no se pueden comunicar a otros dispositivos fuera de su red, pero sí a nivel local.
-El impacto se ha aislado en la comunicación ruteada fuera de la VLAN y el switch actúa como el gateway predeterminado.
-Una verificación de los hosts, indica que no pueden hacer ping al gateway, después de una verificación de su tabla ARP, la entrada para el gateway permanece como Incompleta.
-Todos los demás hosts que tienen la gateway resuelta no tienen problemas de comunicación. Una verificación de CoPP en el switch que actúa como gateway indica que hay violaciones en copp-system-p-class-normal.
class-map copp-system-p-class-normal (match-any)
match access-group name copp-system-p-acl-mac-dot1x
match protocol arp
set cos 1
police cir 1400 kbps , bc 32000 bytes
module 1 :
transmitted 3292445628 bytes;
dropped 522023852 bytes;
-Además, varias verificaciones de comandos, muestran que las caídas están aumentando activamente.
-Estas violaciones pueden hacer que se descarte el tráfico ARP legítimo, lo que conduce a un comportamiento de denegación de servicios.
Nota: Es importante destacar que CoPP aísla el impacto al tráfico asociado con la clase específica, que en este ejemplo son ARP y copp-system-p-class-normal. El tráfico relacionado con otras clases, como OSPF, el BGP no es descartado por CoPP, ya que se encuentran en una clase completamente diferente. Si se deja sin marcar, los problemas ARP pueden entrar en cascada en otros problemas, lo que puede afectar a los protocolos que dependen de ellos para empezar. Por ejemplo, si una memoria caché ARP se agota y no se actualiza debido a violaciones excesivas, una sesión TCP como BGP puede terminar.
-Se recomienda realizar comprobaciones del plano de control, como Ethanalyzer, estadísticas de CPU-mac en banda y procesos de CPU para aislar el asunto aún más.
Dado que el tráfico controlado por CoPP está asociado solamente con el tráfico dirigido a la CPU, una de las herramientas más importantes es el etanalyzer. Esta herramienta es una implementación de Nexus de TShark y permite que el tráfico enviado y recibido por el supervisor se capture y decodifice. También puede utilizar filtros que se basan en criterios diferentes, como protocolos o información de encabezado, convirtiéndose así en una herramienta inestimable para determinar el tráfico enviado y recibido por la CPU.
La recomendación es examinar primero el tráfico ARP visto por el supervisor cuando la herramienta ethanalyzer se ejecuta directamente en la sesión terminal o se envía a un archivo para su análisis. Se pueden definir filtros y límites para centrar la captura en un patrón o comportamiento específico. Para ello, agregue filtros de visualización flexibles.
Un error común es que el etanalyzer captura todo el tráfico que atraviesa el switch. El tráfico del plano de datos, entre hosts, es conmutado o ruteado por los ASIC de hardware entre los puertos de datos no requiere la participación de la CPU y, por lo tanto, normalmente no es visto por la captura del etanalyzer. Para capturar el tráfico del plano de datos, se recomienda utilizar otras herramientas, como ELAM o SPAN. Por ejemplo, para filtrar ARP, utilice el comando:
ethanalyzer local interface inband display-filter arp limit-capture-frames 0 autostop duration 60 > arpcpu
Campos configurables importantes:
-'interface inband' - se refiere al tráfico dirigido al SUP
-'display-filter arp': se refiere al filtro tshark aplicado, se aceptan la mayoría de los filtros Wireshark
-'limit-capture-frames 0' - hace referencia al límite, 0 equivale a ilimitado, hasta que se detiene por otro parámetro o se detiene manualmente mediante Ctrl+C
-'duración de autostop 60' - se refiere a la parada del etanalyzer después de 60 segundos, por lo que crea una instantánea de 60 segundos de tráfico ARP visto en la CPU
El resultado del etanalyzer se redirige a un archivo de la memoria flash de inicialización con '> arpcpu', para su procesamiento manual. Después de 60 segundos, la captura se completa y el analizador etáreo termina dinámicamente, y el archivo arpcpu se encuentra en la memoria flash de inicialización del switch, que luego se puede procesar para extraer los usuarios más activos. Por ejemplo:
show file bootflash:arpcpu | sort -k 3,5 | uniq -f 2 -c | sort -r -n | head lines 50
669 2022-05-10 10:29:50.901295 28:ac:9e:ad:5e:47 -> ff:ff:ff:ff:ff:ff ARP Who has 10.1.1.1? Tell 10.1.1.2
668 2022-05-10 10:29:50.901295 28:ac:9e:ad:5e:43 -> ff:ff:ff:ff:ff:ff ARP Who has 10.2.1.1? Tell 10.2.1.2
668 2022-05-10 10:29:50.901295 28:ac:9e:ad:5e:41 -> ff:ff:ff:ff:ff:ff ARP Who has 10.3.1.1? Tell 10.3.1.2
Este filtro se ordena en función de: las columnas de origen y de destino, las coincidencias únicas encontradas (pero se omite la columna de fecha), cuenta las instancias y agrega el número visto, y finalmente ordena de arriba a abajo, en función del recuento, y muestra los primeros 50 resultados.
En este ejemplo de laboratorio, en 60 segundos, se recibieron más de 600 paquetes ARP de tres dispositivos, que se han identificado como los dispositivos infractores sospechosos. La primera columna del filtro detalla el número de instancias de este evento que se vieron en el archivo de captura durante el tiempo especificado.
Es importante comprender que la herramienta etanalyzer actúa sobre el controlador en banda, que es esencialmente la comunicación al ASIC. En teoría, el paquete necesita pasar a través del núcleo y del administrador de paquetes para ser entregado al proceso asociado en sí. CoPP y HWRL actúan antes de que el tráfico se vea en el etanalyzer. Incluso si las infracciones aumentan de forma activa, parte del tráfico todavía pasa y se ajusta a la velocidad de la policía, lo que ayuda a proporcionar información sobre los flujos de tráfico impulsados a la CPU. Es una distinción importante, ya que el tráfico visto en el analizador etánico NO es el tráfico que violó el CIR y fue descartado.
El etanalyzer también puede utilizarse de forma abierta, sin ningún filtro de visualización o filtro de captura especificado para capturar todo el tráfico SUP relevante. Esto se puede utilizar como medida de aislamiento como parte del enfoque de solución de problemas.
Para obtener más información y utilizar el etanalyzer, consulte la nota técnica:
Nota: Nexus 7000, antes de la versión de código 8.X, solo puede realizar capturas de etanalyzer a través del VDC administrador, que abarca el tráfico con enlace ascendente de todos los VDC. El analizador etánico específico de VDC está presente en los códigos 8.X.
Las estadísticas en banda asociadas con el tráfico ligado a la CPU mantienen estadísticas relevantes del tráfico de CPU TX/RX en banda. Estas estadísticas se pueden verificar con el comando: "show hardware internal cpu-mac inband stats". que proporciona información sobre las estadísticas de velocidad actual y de velocidad pico.
show hardware internal cpu-mac inband stats`
================ Packet Statistics ======================
Packets received: 363598837
Bytes received: 74156192058
Packets sent: 389466025
Bytes sent: 42501379591
Rx packet rate (current/peak): 35095 / 47577 pps
Peak rx rate time: 2022-05-10 12:56:18
Tx packet rate (current/peak): 949 / 2106 pps
Peak tx rate time: 2022-05-10 12:57:00
Como práctica recomendada, se recomienda crear una línea de base y realizar un seguimiento, ya que, según la función del switch y la salida de la infraestructura de las estadísticas de la "show hardware internal cpu-mac inband", varía significativamente. En este entorno de laboratorio, los valores habituales y los picos históricos no suelen ser superiores a unos pocos cientos de pps, por lo que esto es anormal. El comando show hardware internal cpu-mac inband events también es útil como referencia histórica, ya que contiene datos relacionados con el uso pico y la hora en que se detectó.
Los switches Nexus son sistemas basados en Linux, y el sistema operativo Nexus (NXOS) aprovecha el programador preventivo de la CPU, la multitarea y el subprocesamiento múltiple de su arquitectura de núcleos respectiva para proporcionar un acceso justo a todos los procesos y, por lo tanto, los picos no siempre indican un problema. Sin embargo, si se observan violaciones de tráfico sostenidas, es probable que el proceso asociado también se utilice fuertemente y aparezca como un recurso principal bajo las salidas de la CPU. Tome varias instantáneas de los procesos de la CPU para verificar el alto uso de un proceso determinado mediante: show processes cpu sort | excluye 0.0 o show processes cpu sort | grep <process>.
Las verificaciones de CPU de proceso, estadísticas en banda y etanalyzer proporcionan información sobre los procesos y el tráfico actualmente procesado por el supervisor y ayudan a aislar la inestabilidad continua en el tráfico del plano de control que puede caer en cascada en problemas del plano de datos. Es importante comprender que el CoPP es un mecanismo de protección. Es reaccionario porque sólo actúa sobre el tráfico impulsado a la SUP. Está diseñado para salvaguardar la integridad del supervisor mediante el descarte de las velocidades de tráfico que exceden los intervalos esperados. No todas las caídas indican un problema o requieren intervención, ya que su importancia se relaciona con la clase de CoPP específica y el impacto verificado, según la infraestructura y el diseño de la red. Las caídas debidas a eventos esporádicos de ráfaga no se traducen en impacto, ya que los protocolos tienen mecanismos integrados, como keepalive y reintentos que pueden lidiar con eventos transitorios. Mantenga el foco en acontecimientos sostenidos o eventos anormales más allá de las bases de referencia establecidas. Recuerde que CoPP debe adherirse a los protocolos y funciones específicos del entorno y debe supervisarse y repetirse continuamente para ajustarlo a su perfección, en función de las necesidades de escalabilidad a medida que evolucionan. Si se producen caídas, determine si la CoPP descartó el tráfico de forma no intencional o en respuesta a un mal funcionamiento o ataque. En cualquier caso, analizar la situación y evaluar la necesidad de intervenir mediante el análisis del impacto y las medidas correctivas en el medio ambiente, que pueden estar fuera del alcance del propio switch.
Las plataformas/códigos recientes pueden tener la capacidad de realizar un SPAN a la CPU, mediante la duplicación de un puerto y el punt del tráfico del plano de datos a la CPU. Normalmente, esto está muy limitado en función del límite de velocidad de hardware y la CoPP. Se aconseja el uso cuidadoso del SPAN a la CPU y está fuera del alcance de este documento. Consulte la nota técnica que aparece para obtener más información sobre esta función:
Revisión | Fecha de publicación | Comentarios |
---|---|---|
1.0 |
01-Jul-2022 |
Versión inicial |