Down Olan Interface’ler Kendi Kendine Canlansın! 🤖🔄

Related Articles

Cisco BGP Best Path Selection: BGP En İyi Rotayı Nasıl Seçer?

5 gün ago

Ping Çalışıyor, Uygulama Açılmıyor: MTU ve MSS Sorun Giderme

2 hafta ago

🚀 Cisco vPC’yi Anlamak

19 Haziran 2026

Cisco EEM ile Interface Auto-Recovery Mantığı

Yüksek erişilebilirlik gereken ağlarda kritik linklerin beklenmedik şekilde down olması servis kesintisine neden olabilir.

Normalde operasyon ekibi şu adımları manuel yapar:

Interface down alarmı gelir
→ Cihaz kontrol edilir
→ Interface durumu incelenir
→ Gerekirse shutdown / no shutdown yapılır
→ Loglar kontrol edilir
→ Servis geri geldi mi doğrulanır

Bu süreci belirli senaryolarda Cisco Embedded Event Manager — EEM ile otomatikleştirmek mümkündür.

Ancak önemli bir nokta vardır:

Interface down oldu diye otomatik reset her zaman doğru çözüm değildir.

Bu yöntem yalnızca kontrollü, test edilmiş ve sınırlı senaryolarda kullanılmalıdır.

---

Cisco EEM Nedir?

EEM — Embedded Event Manager, Cisco IOS / IOS-XE cihazlarda belirli olayları izleyip otomatik aksiyon çalıştırmaya yarayan yerleşik otomasyon mekanizmasıdır.

EEM şu olaylarla tetiklenebilir:

• Syslog mesajı
• Interface state değişimi
• IP SLA / Track durumu
• Timer
• SNMP event
• CLI event
• Counter / threshold
• Routing event

EEM ile yapılabilecek aksiyonlar:

• Syslog mesajı üretmek
• CLI komutu çalıştırmak
• Interface resetlemek
• Konfigürasyon almak
• Alarm üretmek
• Route değiştirmek
• IP SLA sonucuna göre aksiyon almak
• Basit self-healing otomasyonları yapmak

---

1️⃣ Temel Senaryo

Hedefimiz şu:

GigabitEthernet1/0/1 line protocol down olursa
→ EEM tetiklensin
→ Interface shutdown / no shutdown yapılsın
→ Syslog mesajı bırakılsın
→ Operasyon ekibi logdan görsün

Bu yapı özellikle aşağıdaki durumlarda düşünülebilir:

• Kamera / IoT / access port otomatik toparlama
• Test ortamı link reset senaryosu
• Geçici port kilitlenmesi
• Bilinen ve tekrarlayan access port problemi
• Kritik olmayan ama hızlı toparlanması istenen portlar

---

2️⃣ Basit EEM Applet Örneği

Aşağıdaki örnek, belirli bir interface için syslog mesajını izler ve interface’i resetler.

configure terminal
 event manager applet AutoRecover_Gi1_0_1
  event syslog pattern "LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/1, changed state to down"
  action 1.0 syslog msg "EEM: Gi1/0/1 down algilandi. Otomatik reset baslatiliyor."
  action 2.0 cli command "enable"
  action 3.0 cli command "configure terminal"
  action 4.0 cli command "interface GigabitEthernet1/0/1"
  action 5.0 cli command "shutdown"
  action 6.0 wait 5
  action 7.0 cli command "no shutdown"
  action 8.0 cli command "end"
  action 9.0 syslog msg "EEM: Gi1/0/1 shutdown/no shutdown islemi tamamlandi."
end

Açıklama

event syslog pattern → Belirli syslog mesajını yakalar
action cli command   → IOS CLI komutu çalıştırır
action wait 5        → Shutdown sonrası 5 saniye bekler
syslog msg           → Operasyon logu bırakır

---

3️⃣ Daha Güvenli Kullanım: Cooldown Mantığı

Basit EEM script’i çalışır; fakat interface sürekli down/up oluyorsa cihaz sürekli port resetleyebilir.

Bu risklidir.

Daha güvenli yaklaşım:

Port down oldu
→ EEM bir kez resetledi
→ Belirli süre içinde tekrar down olursa sadece alarm üret
→ Sonsuz shutdown/no shutdown döngüsüne girme

Cisco EEM applet tarafında gelişmiş sayaç/cooldown mantığı platforma göre Tcl veya daha gelişmiş EEM değişkenleriyle tasarlanabilir. Basit kullanımda en azından aşağıdaki kontroller uygulanmalıdır:

• Aynı interface için sürekli reset yapılmamalı
• Log bırakılmalı
• NOC/SIEM alarmı üretilmeli
• Root cause analizi zorunlu tutulmalı
• Kritik uplinklerde otomatik reset kör şekilde kullanılmamalı

---

4️⃣ Err-Disable Senaryosu Ayrı Ele Alınmalı

Interface down ile err-disable aynı şey değildir.

Bir port şu nedenlerle err-disable olabilir:

• BPDU Guard
• Port Security violation
• UDLD
• Link-flap
• Storm-control
• Loopback detection
• DHCP Snooping / DAI ihlalleri
• EtherChannel misconfiguration

Bu durumda kör shutdown/no shutdown yapmak gerçek problemi gizleyebilir.

Err-disable için ayrı yaklaşım gerekir:

show interface status err-disabled
show errdisable recovery
show logging | include ERR|errdisable|PM-4

Bazı durumlarda Cisco’nun yerleşik errdisable recovery mekanizması kullanılabilir:

configure terminal
 errdisable recovery cause link-flap
 errdisable recovery interval 300
end

Kritik Not

BPDU Guard veya port-security gibi güvenlik kaynaklı err-disable durumlarında otomatik recovery dikkatli kullanılmalıdır.

Çünkü portu otomatik açmak loop veya yetkisiz cihaz riskini tekrar devreye alabilir.

---

5️⃣ Kritik Uplinklerde Dikkat

Bu script access port için makul olabilir; fakat kritik uplink, trunk, port-channel member veya core bağlantılarında çok dikkatli kullanılmalıdır.

Riskli port tipleri:

Core uplink
Distribution uplink
Port-channel member
Firewall bağlantısı
Router transit link
Storage network
VPC / MLAG peer-link
Stack / fabric link

Bu portlarda interface resetlemek daha büyük kesinti yaratabilir.

Kritik uplinklerde daha doğru yaklaşım:

• BFD
• IP SLA + Track
• Routing failover
• Port-channel yedekliliği
• UDLD
• Link monitoring
• NMS/SIEM alarmı
• Manuel onaylı aksiyon
• Bakım penceresi

---

6️⃣ Doğrulama Komutları

EEM applet’in kayıtlı olup olmadığını kontrol edin:

show event manager policy registered

EEM event geçmişini kontrol edin:

show event manager history events

Loglarda EEM mesajlarını arayın:

show logging | include EEM
show logging | include AutoRecover
show logging | include LINEPROTO

Interface durumunu kontrol edin:

show interface GigabitEthernet1/0/1 status
show interface GigabitEthernet1/0/1
show logging interface GigabitEthernet1/0/1

---

7️⃣ Manuel Test

EEM script’ini üretime almadan önce lab veya bakım penceresinde test edin.

Test akışı:

1. Applet’i oluştur.
2. show event manager policy registered ile doğrula.
3. Interface’i kontrollü down et.
4. Syslog tetiklendi mi kontrol et.
5. EEM action çalıştı mı kontrol et.
6. Interface tekrar up oldu mu doğrula.
7. Loglarda timestamp ve aksiyon sırasını incele.

Kontrollü test:

configure terminal
 interface GigabitEthernet1/0/1
  shutdown
end

Ardından:

show event manager history events
show logging | include EEM
show interface GigabitEthernet1/0/1 status

---

8️⃣ Daha Güvenli Örnek: Önce Alarm, Sonra Reset

Üretimde doğrudan reset yerine önce alarm üretmek daha güvenlidir.

configure terminal
 event manager applet Gi1_0_1_Down_Alert
  event syslog pattern "LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/1, changed state to down"
  action 1.0 syslog msg "EEM-ALERT: Gi1/0/1 down oldu. Otomatik reset yapilmadi. NOC kontrol etmeli."
end

Bu modelde EEM sadece alarm üretir. Otomatik müdahale yapılmaz.

Daha sonra portun gerçekten resetlenebilir olduğu doğrulanırsa auto-recovery versiyonu devreye alınabilir.

---

9️⃣ IP SLA / Track ile Alternatif Yaklaşım

Interface fiziksel olarak up olabilir ama karşı uç servis vermiyor olabilir.

Bu durumda syslog interface down yakalamak yeterli olmaz.

Daha doğru yaklaşım:

IP SLA hedefi izle
→ Track down olursa EEM tetikle
→ Alarm üret veya kontrollü aksiyon al

Örnek kullanım alanı:

• WAN next-hop erişilemiyor
• Metro Ethernet path bozuk
• Firewall arkasındaki hedef cevap vermiyor
• Fiziksel link up ama servis yok

Bu senaryolarda sadece interface state değil, gerçek erişilebilirlik izlenmelidir.

---

10️⃣ Faydaları

Saniyeler İçinde Müdahale

Manuel operasyon beklenmeden basit toparlama aksiyonu alınabilir.

Kesintiyi Kısaltma

Belirli port kilitlenmesi veya geçici interface problemi hızlıca toparlanabilir.

Operasyonel Otomasyon

EEM ile tekrar eden basit işlemler cihaz üzerinde otomatikleştirilebilir.

Log ve İzlenebilirlik

Syslog mesajlarıyla ne zaman, hangi aksiyonun çalıştığı görülebilir.

Kolay Genişletme

Benzer yapı başka interface veya syslog pattern’leri için uyarlanabilir.

---

11️⃣ Sık Yapılan Hatalar

1️⃣ Her Down Olayında Port Resetlemek

Bu, gerçek kök nedeni gizleyebilir ve daha büyük kesinti yaratabilir.

2️⃣ Kritik Uplinklerde Kör Kullanmak

Core, trunk, port-channel veya firewall bağlantılarında otomatik reset risklidir.

3️⃣ Döngü Koruması Eklememek

Interface sürekli down/up oluyorsa EEM sürekli tetiklenebilir.

4️⃣ Err-Disable Sebebini İncelemeden Açmak

BPDU Guard veya port-security ihlali varsa portu otomatik açmak güvenlik riskidir.

5️⃣ Loglama Yapmamak

Otomasyon çalıştı ama log yoksa olay sonrası analiz zayıflar.

6️⃣ Pattern’i Çok Genel Yazmak

Genel syslog pattern yanlış interface’lerde tetiklenmeye neden olabilir.

Yanlış:

event syslog pattern "changed state to down"

Daha doğru:

event syslog pattern "Line protocol on Interface GigabitEthernet1/0/1, changed state to down"

---

12️⃣ 48s Mini-PoC Planı

1. Kritik olmayan bir test interface seçin.
2. EEM applet’i sadece alarm üretecek şekilde oluşturun.
3. Interface’i kontrollü shutdown yaparak tetiklenmeyi doğrulayın.
4. show event manager history events ile event geçmişini kontrol edin.
5. Sonra shutdown/no shutdown aksiyonlarını ekleyin.
6. action wait ile kısa bekleme süresi tanımlayın.
7. Script’in tekrar tekrar tetiklenmediğini doğrulayın.
8. Logları SIEM/NMS tarafına gönderin.
9. Aynı yapıyı üretim portlarına uygulamadan önce risk sınıflandırması yapın.
10. Kritik portlar için otomatik reset yerine alarm/onay mekanizması kullanın.

---

Örnek Üretim Politikası

Access port / kamera / IoT portu:
  EEM auto-recover değerlendirilebilir.

Uplink / trunk / port-channel:
  Otomatik reset önerilmez.
  Alarm + manuel onay tercih edilir.

Err-disable güvenlik nedeni:
  Otomatik açma dikkatli kullanılmalı.
  Önce root cause incelenmeli.

WAN path problemi:
  Interface reset yerine IP SLA / BFD / routing failover tercih edilmeli.

---

Sonuç

Cisco EEM, interface down gibi olaylara otomatik tepki vermek için güçlü ve pratik bir araçtır.

Ancak doğru kullanılmadığında “self-healing” yerine “self-flapping” üretebilir.

Bu nedenle en sağlıklı yaklaşım şudur:

Önce alarm üret.
Sonra kontrollü reset yap.
Kritik portlarda otomatik aksiyonu sınırla.
Her zaman log bırak.
Root cause analizini ihmal etme.

EEM ile interface auto-recovery, doğru senaryoda kesintiyi kısaltır; yanlış senaryoda ise problemi büyütür.

Bu yüzden üretim ortamında her zaman test, sınırlama, izleme ve rollback planı ile birlikte kullanılmalıdır.