Perché proteggere l’infrastruttura a livello di control plane

Un router o switch enterprise non inoltra soltanto pacchetti nel data plane: deve anche elaborare protocolli di routing (OSPF, EIGRP, BGP), traffico di management (SSH, SNMP, NTP) e servizi Layer 2/3 come ARP. Tutto questo converge verso la CPU nel control plane. Due strumenti fondamentali per difendere questa superficie sono le ACL (filtro selettivo del traffico) e il Control Plane Policing (CoPP) (rate-limit del traffico destinato alla CPU).

ACL standard vs extended

Un’ACL è una lista ordinata di ACE (Access Control Entry) valutate top-down. Esistono due famiglie principali:

Tipo Range numerico Cosa matcha Uso tipico
Standard 1–99, 1300–1999 solo source IP filtro grossolano, VTY access-class, route-map
Extended 100–199, 2000–2699 source, destination, protocollo, porta L4 filtro granulare su interfacce, QoS, CoPP

Le ACL standard decidono unicamente in base all’indirizzo sorgente: non conoscono destinazione né porta. Per questo la best practice le colloca vicino alla destinazione, per non bloccare troppo traffico a monte. Le ACL extended matchano l’intera 5-tuple e vanno posizionate vicino alla sorgente, così da scartare il traffico indesiderato il prima possibile.

Le ACL denominate (named) sono oggi preferite: consentono di riferire e modificare singole ACE per numero di sequenza senza riscrivere l’intera lista.

ip access-list extended BLOCK-TELNET
 10 deny tcp any any eq 23
 20 permit ip any any

Ordine di valutazione e deny implicito

Questo è il cuore concettuale (e la trappola d’esame più frequente). Le regole:

  • Valutazione top-down: la prima ACE che matcha decide l’esito; le successive non vengono considerate.
  • Un’entry generica messa troppo in alto “maschera” (shadowing) le entry specifiche sottostanti, che diventano irraggiungibili. Le ACE più specifiche vanno sopra quelle generiche.
  • In coda a ogni ACL esiste un deny any implicito invisibile: tutto ciò che non è esplicitamente permesso viene scartato. Se un’ACL contiene solo deny, senza almeno un permit, blocca tutto.

Ne consegue che serve sempre almeno una permit esplicita per il traffico legittimo, e che l’ordinamento delle ACE è funzionale, non estetico.

Control Plane Policing (CoPP)

Il CoPP applica una policy QoS alla control-plane interface, filtrando e limitando in rate il traffico che raggiunge la CPU. Protegge da tempeste di traffico (ARP flood, scan, DoS verso il router) che, pur non riguardando il transito, potrebbero saturare la CPU e far cadere adiacenze OSPF/BGP.

La configurazione segue il classico modello MQC (Modular QoS CLI): class-map per classificare il traffico (spesso con ACL match), policy-map per definire azioni police con rate e comportamento su conform/exceed, e applicazione con service-policy input sotto control-plane.

control-plane
 service-policy input COPP-POLICY

Principi chiave da ricordare:

  • CoPP si applica solo input verso il control plane (il traffico diretto alla CPU), non al traffico in transito.
  • Le classi vanno differenziate per criticità: i protocolli di routing (OSPF, BGP, EIGRP) e il management essenziale (SSH) ricevono banda garantita o generosa; ARP, ICMP e traffico ignoto vengono limitati più aggressivamente.
  • Una policy troppo restrittiva può far cadere adiacenze o bloccare l’accesso di gestione: il rate va dimensionato con margine.
  • Su piattaforme IOS-XE esiste anche il CPP hardware (platform control-plane) e default già presenti; verificare sempre con show policy-map control-plane.

Trappole tipiche d’esame

  • ACE generica sopra le specifiche → shadowing: scenario con permit ip any any (o un deny largo) posto prima di una regola puntuale. La risposta giusta riordina le ACE mettendo le più specifiche in cima; la generica in fondo.
  • Deny any implicito dimenticato: un’ACL con soli permit per pochi host blocca tutto il resto anche se “non c’è scritto deny”. Se il traffico legittimo cade, aggiungere il permit mancante prima del deny finale.
  • ACL standard usata dove serve granularità: scenario che chiede di filtrare per porta/destinazione con una standard (solo source) → serve una extended.
  • CoPP applicata al posto sbagliato: CoPP agisce sotto control-plane in input; non filtra il traffico in transito né si mette su un’interfaccia fisica.
  • Rate CoPP troppo basso sui routing protocol: se dopo l’applicazione della policy cadono le adiacenze OSPF/BGP, la classe dei protocolli di routing è sotto-dimensionata o mal classificata, non “il protocollo è instabile”.