Podcast: Descargar (Duración: 19:44 — 19.4MB)
Cisco tiene una cosa llamada Cisco CoPP Policy que lo que hace es proteger el plano de control de los routers Cisco ante un supuesto ataque.
Los conceptos de Plano de Control (control Plane) y Plano de Datos (Data plane) se refieren a la separación lógica, y en algunos escenarios física, del trafico destinado a los Servicios (Data plane) y el tráfico que ocupan los Equipos de Red para gestionar, mantener y modificar el estado de la misma (Control Plane).
https://community.cisco.com/t5/discusiones-data-center/plano-de-control-y-plano-de-datos/td-p/2820763
Por poner un ejemplo muy sencillo podemos estar inundando ICMPs contra la IP del router, ese tráfico lo tiene que procesar el propio router, la procesadora y eso al final va a afectar al plano de control ya que es ahí donde se ejecutan todas aquellas «cosas» que hacen que se pueda mover el tráfico con normalidad por el plano de datos.
Si un PC a en un puerto del switch le manda un ping a un PC en otro puerto del switch ese tráfico irá sólo por el plano de datos del switch.
Ahora, si un router está pinchado en un puerto de un switch y otro router está pinchado en otro puerto del mismo switch el tráfico entre ellos irá directo por el plano de datos, pero los servicios de red irán por el plano de control y en este caso los servicios de red serán mensajes de STP, VRRP, HSRP, OSPF, RIP ….
Esto lo tenéis documentado en la propia web de Cisco en https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus6000/sw/security/6x/b_6k_Security_Config_6x/b_6k_Security_Config_602N12_chapter_01101.pdf
En equipos como los Nexus7k, el Data plane es procesado por los Módulos, sin tener que pasar por la Supervisora, quien se encarga de procesar el tráfico de Control Plane propio de la Red, por ejemplo, Updates de Routing Protocols, Mensajes de Fabricpath, OTV, etc.
https://community.cisco.com/t5/discusiones-data-center/plano-de-control-y-plano-de-datos/td-p/2820763
El otro plano que tenemos es el de gestión pero que en este capítulo vamos a obviarlo bastante.
Hemos dicho que el objetivo es proteger a nuestra procesadora de tener que procesar aquello que no debiera y que debería de ser tratado por el ASIC correspondiente.
Para proteger a nuestro router tendremos que indicar qué puerto queremos proteger, podemos hacerlo por puertos sueltos o mediante un puerto lógico llamado «Control Plane» que incluirá a todos los puertos del router o del switch.
Al control plane le tendremos que aplicar un policing para limitar el tráfico que queremos que nos llegue.
Para identificar el tráfico al que queremos hacer el rate limit tenemos que crear un class-map en nuestro cisco.
Si el tráfico hace match con el class-map entonces tendremos que aplicar el polily-map para aplicar la política correspondiente, el rate limit.
Y por último tenemos que decir donde aplicar esta política y esto lo podemos hacer en el control plane, es decir, todos los puertos y en los interfaces individuales.
El primer paso con esto que hemos dicho es crear el class-map. Como ya sabéis el class-map en cisco se aplica sobre un access-list, así que definimos el access-list y luego aplicamos el class-map
! access-list 120 permit tcp any gt 1024 <router receive block> eq bgp access-list 120 permit tcp any eq bgp <router receive block> gt 1024 established access-list 120 permit tcp any gt 1024 <router receive block> eq 639 access-list 120 permit tcp any eq 639 <router receive block> gt 1024 established access-list 120 permit tcp any <router receive block> eq 646 access-list 120 permit udp any <router receive block> eq 646 access-list 120 permit ospf any <router receive block> access-list 120 permit ospf any host 224.0.0.5 access-list 120 permit ospf any host 224.0.0.6 access-list 120 permit eigrp any <router receive block> access-list 120 permit eigrp any host 224.0.0.10 access-list 120 permit udp any any eq pim-auto-rp ---etc--- for other routing protocol traffic... !
Con esto ya tendríamos creado el access-list 120 que lo vamos a usar para el tráfico de routing y ya podemos crear el class-map, que en este caso lo hemos llamado Routing.
! class-map match-all Routing match access-group 120 !
Perfecto, en este punto ya hemos identificado el tráfico que queremos limitar, al que queremos hacer rate limit. Ahora el policy-.map tiene una estructura un poco caprichosa:
router(config) policy-map <service_policy_name> router(config-pmap) class <traffic_class_name> router(config-pmap-c) police [cir | rate] conform-action [transmit | drop] exceed-action [transmit | drop] where: * cir – Committed information rate (bits per second) * rate – Policy rate in packets per second (pps)
En nuestro ejemplo con el tráfico de routing:
! policy-map RTR_CoPP class Undesirable police 8000 1500 conform-action drop exceed-action drop class Routing police 1000000 50000 conform-action transmitexceed-action transmit class Management police 100000 20000 conform-action transmit exceed-action drop class Normal police 50000 5000 conform-action transmit exceed-action drop class Catch-All-IP police 50000 5000 conform-action transmit exceed-action drop class class-default police 8000 1500 conform-action transmit exceed-action transmit !
Aquí tenemos dos opciones para configurar el policy, una es con el Committed Information Rate in pps, el Committed Burst Size in packets y luego el conform o bien simplemente indicando el límite en pps.
Y ya tenemos el policy-map, ahora tendremos que definir el service-policy.
! control-plane service-policy input RTR_CoPP !
De esta forma ya tendríamos aplicado en el plano de control un service-policy que que en el tráfico de entrada tiene un policy-map que dice que al tráfico de Routing.