Batfish ile Network Değişikliği Ön Doğrulama Pipeline’ı

Network’te en pahalı hata sınıfı şudur: değişiklik doğru görünüyor ama bir yerde reachability/ACL yan etkisi oluşturuyor. Prod’da yakaladığında çözüm “geri al” olur; ama bazı ortamlarda geri almak da risklidir (çoklu bağımlılık, eşzamanlı değişiklikler, state).

Bu yazıda sahada defalarca işime yarayan akışı anlatıyorum:

1. config snapshot al
2. Batfish ile soru setini çalıştır
3. sonuç “beklenen” değilse merge’ü durdur

Hedef: Her PR’da aynı 6 soruya cevap

Benim minimum setim:

• Bu değişiklikle hangi prefix’ler unreachable oldu?
• Yeni bir ACL/route‑policy ile hangi trafik kesildi?
• Default route / next‑hop davranışı değişti mi?
• BGP/OSPF komşuluğu beklendiği gibi mi?
• VRF’ler arası sızıntı (leak) oluştu mu?
• “Sadece şurada” diye açtığın izin, başka yerde büyüdü mü?

Kurulum: Batfish’i konteynerle ayağa kaldır

En pratik yaklaşım Docker.

docker run --rm -d --name batfish -p 9997:9997 -p 9996:9996 batfish/allinone

Batfish iki arayüzle gelir (sürümüne göre değişebilir):

• service (analiz motoru)
• client (pybatfish üzerinden konuşursun)

Snapshot yapısı: config + environment

Batfish snapshot’ı temel olarak şunları içerir:

• Cihaz config’leri (vendor formatında)
• (Opsiyonel) interface/status/env verileri

Örnek repo düzeni (öneri):

network/
  snapshots/
    prod/
      configs/
        r1.cfg
        r2.cfg
      hosts/
        host1.json

Bu sayede “prod snapshot” sabit kalır; PR değişikliği yeni snapshot üretir.

Soru seti: PR’ı kıran 3 kritik test

1) Reachability: beklenen akış var mı?

Örnek soru: “app VLAN’dan DB VLAN’a TCP/5432 çalışıyor mu?”

• source: app subnet
• destination: db subnet
• protocol/port: tcp/5432

2) ACL: beklenmeyen deny oluştu mu?

Özellikle “deny by default” yapan policy’lerde, yanlış sıra büyük incident çıkarır.

3) Routing: next‑hop değişti mi?

BGP local‑pref, route‑map veya IGP metric oynadığında beklenmedik hairpin çıkabilir.

CI/CD: GitHub Actions ile PR gate

Akış:

1. PR branch’inde snapshot üret (config render / export)
2. Batfish container’ı çalıştır
3. Soru setini çalıştır
4. Fail ise workflow fail → merge yok

Basit bir workflow iskeleti:

name: network-precheck
on:
  pull_request:
jobs:
  batfish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Start Batfish
        run: docker run --rm -d --name batfish -p 9997:9997 -p 9996:9996 batfish/allinone
      - name: Run questions
        run: |
          python -m pip install --quiet pybatfish
          python scripts/batfish_questions.py --snapshot network/snapshots/pr

Bu repoda script örneğini özellikle koymuyorum; çünkü her kurumun soru seti farklı. Ama şablon aynı: snapshot + soru + gate.

Operasyonel tavsiyeler (sahada fark yaratanlar)

• Snapshot’ı “gerçeğe yakın” tut: render edilen config’i kullan (templating varsa)
• Soru setini az tut ama kritikleri seç (6–10 soru)
• Fail çıktısını “aksiyon aldıran” formatta ver: hangi prefix, hangi ACL, hangi cihaz
• Change ticket’lara Batfish raporunu ekle (audit ve güven)

Sonuç

Batfish ile yaptığın şey aslında şu: network’ü “kod” gibi ele alıp, değişikliği test edilebilir hale getirmek. Bu yaklaşım, özellikle büyük ağlarda change riskini dramatik şekilde düşürür ve “prod’da fark ettik” cümlesini azaltır.