Bir router/switch’in en kritik parçası forwarding ASIC’i değil, control plane’dir: routing adjacency, yönetim erişimi, ARP/ND, protokol timer’ları… Control plane zorlanırsa, veri düzlemi “çalışıyor gibi” görünür ama sistem hızla kararsızlaşır: adjacency flap, yönetim erişimi kaybı, hatta full outage.
CoPP/CPP (vendor’a göre isim değişir) bu yüzden “güvenlik” kadar dayanıklılık kontrolüdür: control plane’e gelen trafiği sınıflandırır, önceliklendirir ve limitler.
Tehdit modeli: control plane’i kimler yorar?
Sahada en sık gördüğüm control-plane zorlanma kaynakları:
- Scan/flood: ICMP, TCP SYN, yönetim portları (SSH/SNMP) taramaları
- Yanlış telemetry: agresif polling (SNMP), hatalı trap fırtınası
- Routing patlaması: flap, yanlış komşu, LSA/LSP fırtınası
- L2 anomali: ARP/NDP patlaması, loop, storm
- Kötü ACL/punt: beklenmeyen trafik CPU’ya punt olur
CoPP, bu trafiği “hepsini drop” diye ele almaz; kritik sınıfları garanti altına alır, gürültüyü kısar.
Tasarım ilkeleri: CoPP bir “policy seti” değil, canlı model
CoPP için sahada çalıştığını gördüğüm ilkeler:
- Routing önce: BGP/OSPF/IS-IS gibi protokoller en yüksek öncelik sınıfında.
- Yönetim sınırlı ama stabil: SSH/SNMP var; ama rate-limit ve kaynak kısıtı ile.
- ICMP akıllı: tamamen kapatma; fakat flood’u kes.
- Default drop / low rate: bilinmeyen punt trafiği düşük eşikle sınırla.
- Gözlem şart: sayaçlar + CPU + drops, alarm setine bağlanır.
Sınıf tasarımı: minimum viable control-plane policy
Ürün bağımsız minimum sınıflar:
1) Routing control
- BGP, OSPF/IS-IS, BFD, VRRP/HSRP (kullandığınıza göre)
- Hedef: adjacency stabil kalsın, flap fırtınasında bile CPU kilitlenmesin
2) Yönetim erişimi
- SSH, API, SNMPv3, TACACS/RADIUS (yönetim düzleminiz neyse)
- Hedef: incident’te cihaza erişim kaybolmasın
3) L2/L3 altyapı sinyalleri
- ARP/ND, DHCP relay control, NTP (kullanıma göre)
- Hedef: temel altyapı sinyalleri akmaya devam etsin, patlamada sınırlansın
4) ICMP ve diagnostik
- Ping/traceroute gibi gerekli trafik
- Hedef: triage mümkün kalsın, flood kesilsin
5) Default punt / unknown
- Beklenmeyen punt edilen her şey
- Hedef: bilinmeyen trafik CPU’yu ezemesin
Eşik belirleme: ‘kaç pps?’ sorusunu baz çizgi ile cevapla
En kritik soru: “Rate limit kaç olsun?” Cevap; cihaz modelinden çok sizin normal trafik profiliniz.
Pratik yöntem:
- Normal günde punt trafiği sayaçlarını izle (en az 7 gün)
- 95p/99p değerleri çıkar
- Eşiği “normalin biraz üstü” + burst toleransı ile koy
- Alarmı: limit’e yaklaşma + drop artışı üzerine kur
Rollout planı: canary + dalga + geri dönüş
CoPP devreye alırken en güvenli işletme modeli:
- Canary cihaz seç (kritik ama tekil olmayan bir node)
- Policy’yi “monitor ağırlıklı” başlat (düşük riskli sınıflarla)
- 24–48 saat gözlem: drops, CPU, adjacency
- Sonra dalga dalga yay
- Geri dönüş: tek komutla disable/rollback prosedürü hazır olsun
Kapanış
CoPP/CPP; control plane’i “her şeyin konuştuğu bir port” olmaktan çıkarıp, sınıflandırılmış bir hizmet düzlemine dönüştürür. Sahada farkı şu yaratır: incident’te en çok ihtiyacınız olan iki şey (routing stabilitesi + yönetim erişimi) daha az kırılgan olur.