Switch ve Router Firmware Güncelleme Politikası: Sürüm, EoL ve Sıra

Ağ cihazlarında firmware iki uçta yaşar: ya switch ilk kurulduğu sürümde yıllarca unutulur ya da bir güvenlik bildiriminden sonra ön kontrol yapılmadan, gece yarısı telaşla güncellenir. İkisi de arıza üretir. Aşağıda tekrarlanabilir bir politikanın parçalarını sahada uyguladığımız sırayla anlatıyoruz: hangi sürüm seçilir, güvenlik bildirimleri ve yaşam döngüsü tarihleri nasıl izlenir, güncelleme hangi sırayla ve hangi güvenlik ağlarıyla yapılır.

Güncellemeyi ne ertelemek ne de aceleye getirmek

Cisco IOS XE, NX-OS, Juniper Junos, Aruba AOS-CX gibi ağ işletim sistemleri yönetim düzleminde SSH, HTTP(S) sunucusu, SNMP ve çeşitli otomasyon arayüzleri çalıştırır. Bu bileşenlerdeki bir açık, yönetim arayüzü yanlışlıkla erişilebilir bırakılmış bir cihazda doğrudan cihazın ele geçirilmesi demektir. Eski sürümde kalmanın ikinci bedeli daha sessizdir: üreticinin çoktan düzelttiği bellek sızıntısı, belirli bir SFP ile link flap ya da stack üyesinin düşmesi sizin cihazınızda yaşamaya devam eder. Siz de saatlerce bilinen bir hatayı teşhis etmeye çalışırsınız.

Her yeni sürümü hemen kurmak da çözüm değil. Yeni bir özellik dalının ilk bakım sürümleri sahada yeterince çalışmamış kod taşır. Hedef “en yeni sürüm” değildir; bilinen riski kabul edilebilir düzeyde tutan, desteklenen ve test edilmiş sürümdür. Bunun için üç karar yazıya dökülür: hangi sürüm dalı kullanılacak, değerlendirme ne sıklıkla yapılacak ve hangi durumda olağan döngü beklenmeden acil güncelleme yapılacak. Yazılı değilse politika yoktur.

Sürüm seçimi: önerilen sürüm, uzun ömürlü dal, yeni özellik dalı

Üreticilerin çoğu sürümleri bakım süresine göre ayırır. Cisco IOS XE’de bazı dallar “Extended Maintenance” olarak işaretlenir ve daha uzun süre hata düzeltmesi alır; “Standard Maintenance” dallarının desteği daha erken biter. Cisco yazılım indirme sayfasında ayrıca “Suggested” (önerilen) işaretli sürümler bulunur. Juniper platform bazında “JTAC Recommended” listesi yayımlar. Adlandırma değişir, mantık aynı kalır.

Sahadaki pratik kural: aynı rol ve modeldeki cihazlar aynı sürümde tutulur ve rol bazında bir “altın sürüm” (golden image) listesi yazılır. Örneğin “erişim switch’leri: X sürümü; çekirdek: Y sürümü”. Liste bir değişiklik kaydıyla güncellenir, envanterden sapan cihazlar raporlanır. Aynı katmanda üç farklı sürüm çalışan bir ağda sorun giderirken davranış farkının hangi koddan geldiğini ayırmak çok zorlaşır. Sürüm dağınıklığı teşhisi uzatır.

Release notes’ta okunacak bölümler bellidir: desteklenen yükseltme yolu (bazı sürümlere ara sürüm üzerinden geçilir), ROMMON/bootloader veya FPGA güncellemesi gerekip gerekmediği, kaldırılan özellikler ve varsayılan davranış değişiklikleri, açık hatalar (open caveats) listesinde kullandığınız özelliklere dokunan kayıtlar. Sahada en sık atlanan bölüm sonuncusudur.

Güvenlik bildirimleri ve EoS/EoL takibi

Güvenlik takibinin kaynağı üreticinin bildirim sayfasıdır: Cisco için PSIRT yayınları ve Cisco Software Checker aracı, Juniper için güvenlik bültenleri. Her bildirimde aynı dört soruyu sorun. Etkilenen özellik bizde açık mı? Etkilenen sürüm dalında mıyız? Geçici çözüm (özelliği kapatmak, erişimi ACL ile kısıtlamak) var mı? Açık aktif olarak istismar ediliyor mu? Son soru için CISA’nın Known Exploited Vulnerabilities kataloğu iyi bir ikinci kaynaktır; katalogda olan ve sizin cihazınızı etkileyen bir açık, olağan döngüyü beklemeden acil güncelleme gerekçesidir.

Yaşam döngüsü tarafında üreticiler ürün için kilometre taşları yayımlar. Cisco’nun EoS/EoL politikasına göre başlıcaları şunlardır: End-of-Sale (ürün artık satılmaz), End of SW Maintenance Releases (hata düzeltmeli yeni yazılım çıkmaz), End of Vulnerability/Security Support (güvenlik düzeltmesi çıkmaz) ve Last Date of Support (donanım ve yazılım desteği tamamen biter). Operasyonda asıl tarih güvenlik desteğinin bittiği gündür. O günden sonra çıkan açığa yama gelmez.

Tarihleri ezbere ya da üçüncü taraf listelerden almayın; her model için üreticinin güncel EoL duyurusunu açıp envantere işleyin. Envanterde model, seri numarası, mevcut sürüm, hedef sürüm, destek sözleşmesi bitişi ve güvenlik desteği bitiş tarihi aynı satırda durmalı. Bütçe planı, cihaz değişimi ve sözleşme yenilemesi böylece tek tablodan okunur.

Güncelleme öncesi kontroller ve imaj bütünlüğü

Güncellemeden önce aşağıdaki bilgiler toplanır ve değişiklik kaydına eklenir. Güncel konfigürasyon yedeği pazarlık konusu değildir; otomatik ve sürümlü yedekleme için Oxidized ile konfigürasyon yedekleme yazısına bakabilirsiniz.

• Mevcut sürüm, boot değişkeni ve kurulum modu: show version, show boot, IOS XE’de show install summary
• Donanım envanteri ve modüller: show inventory, stack’te show switch
• Flash’ta boş alan: dir flash:; yetersizse eski paketlerin temizliği
• Lisans durumu ve yeni sürümde lisans modelinin değişip değişmediği
• Çalışan konfigürasyonun kaydedildiği: running-config ile startup-config arasında fark olmadığı
• Konsol veya out-of-band erişimin test edildiği
• Komşuluk ve port durumunun “önce” çıktısı (doğrulamada kullanılacak)

İmaj bütünlüğü atlanmaz. Üreticinin indirme sayfasında her imaj için bir özet değeri yayımlanır (Cisco’da MD5 ve SHA512). Dosyayı önce indirdiğiniz sunucuda, sonra cihaza kopyaladıktan sonra cihaz üzerinde doğrulayın:

# Dosya sunucusunda
sha512sum cat9k_iosxe.<surum>.SPA.bin

# Cisco IOS / IOS XE cihaz üzerinde
copy scp://yonetici@10.10.99.20/cat9k_iosxe.<surum>.SPA.bin flash:
verify /md5 flash:cat9k_iosxe.<surum>.SPA.bin
! Platform destekliyorsa SHA512 ile:
verify /sha512 flash:cat9k_iosxe.<surum>.SPA.bin

Hangi algoritmayı kullandıysanız, üreticinin aynı algoritma için yayımladığı değerle karşılaştırın. Değer birebir tutmuyorsa dosya kullanılmaz. Eksik kopyalanmış imajla verilen reload, cihazı ROMMON’da bırakabilir; uzak lokasyonda bu, birinin konsol kablosuyla sahaya gitmesi demektir. İmajı yalnızca üreticinin resmi portalından indirin. Forumdan veya paylaşım sitesinden gelen imaj, özet değeri tutsa bile kaynağı doğrulanamadığı için kabul edilmez.

Stack, yedekli çekirdek ve AP’lerde sıralı güncelleme

Kesinti etkisini sıra belirler. Kural basit: en az kritik ve en kolay geri dönülebilir cihazdan başlayın. Önce laboratuvar veya pilot cihaz, sonra az kullanıcılı bir erişim switch’i, ardından erişim katmanının geri kalanı, en son dağıtım ve çekirdek.

Stack’lenmiş erişim switch’leri

Fiziksel stack (Cisco StackWise vb.) tek yönetim ve kontrol düzlemidir; tüm üyeler aynı sürümü çalıştırmak zorundadır. Catalyst 9000 serisinde install modunda güncelleme şu akışla yapılır:

install add file flash:cat9k_iosxe.<surum>.SPA.bin activate commit
! Cihaz yeniden başladıktan sonra
show version
show install summary
show switch

Bu komut stack’in tüm üyelerini birlikte yeniden başlatır; stack’e bağlı her uç cihaz reload süresince kesilir. Stack güncellemesi bakım penceresi işidir. Komut commit olmadan (install add file … activate) verilirse yeni sürüm etkinleşir ama kalıcı olmaz; otomatik iptal zamanlayıcısı dolmadan install commit verilmezse cihaz önceki sürüme döner. Uzaktan yapılan güncellemede bu davranış ek bir güvenlik ağıdır. Platformunuzdaki kesin davranışı ilgili sürümün yükseltme kılavuzundan doğrulayın.

Yedekli çekirdek: iki ayrı kontrol düzlemi

MLAG, vPC veya bağımsız iki çekirdek switch kullanan tasarımlarda cihazlar tek tek güncellenir: birinci cihaz güncellenir, trafik ikinci cihazdan akarken birinci doğrulanır, sonra ikinciye geçilir. Ön koşul, her uç cihazın gerçekten iki çekirdeğe de bağlı olmasıdır. Sahada en sık gördüğümüz sürpriz, kâğıt üzerinde çift bağlı olan ama ikinci bacağı yıllar önce sökülmüş bir sunucudur; güncellenen çekirdek yeniden başlarken o sunucu kesilir. Pencereden önce port-channel üyelerini tek tek kontrol edin. Fiziksel stack, MLAG ve vPC farkları için switch stack, MLAG ve vPC karşılaştırması yazısına bakın. İki cihaz arasındaki sürüm farkı, üreticinin desteklediği kombinasyon ve süreyle sınırlı kalmalıdır.

Kablosuz erişim noktaları

Kontrolcülü kablosuz ağlarda AP yazılımı kontrolcü sürümüne bağlıdır; kontrolcü yükseltilince AP’ler yeni imajı indirir. Birçok kontrolcü imajın AP’lere önceden indirilmesini (pre-download) ve AP’lerin gruplar halinde, komşu AP’ler aynı anda kapanmayacak şekilde yeniden başlatılmasını destekler. Bulut yönetimli sistemlerde güncelleme zamanı genellikle site bazında ayarlanır. Varsayılan otomatik güncelleme saatinin işletme saatlerine denk gelip gelmediğini kontrol edin.

Geri dönüş planı ve güncelleme sonrası doğrulama

“Sorun olursa eski sürüme döneriz” bir plan değildir. Planda şunlar yazılı olur: eski imaj flash’ta duruyor mu, geri dönüş yöntemi ne (install modunda rollback, bundle modunda boot değişkenini eski imaja çevirip reload), yeni sürümde dönüştürülen konfigürasyon eski sürümde aynen çalışır mı, geri dönüş kararını kim ve hangi ölçüte göre verir. Geri dönüş süresi de bakım penceresinin içinde hesaplanır.

Doğrulama, güncelleme öncesi alınan çıktılarla karşılaştırmalı yapılır:

show version | include uptime|Version
show interfaces status | include connected
show etherchannel summary
show spanning-tree root
show ip ospf neighbor
show cdp neighbors
show logging

Bağlı port sayısı, port-channel üyeleri, STP kök köprüsü ve yönlendirme komşulukları önceki durumla aynı olmalı. Loglarda tekrarlayan hata, modül uyarısı veya lisans mesajı varsa pencere kapatılmadan incelenir. Güncelleme sonrası en az bir iş günü süren bir gözlem dönemi tanımlayın; bellek, CPU ve arayüz hata sayaçları izleme sisteminde önceki haftayla karşılaştırılır. Bellek sızıntısı ilk saatte görünmez. Yürütme disiplini, ön kayıt ve go/no-go kararı için ağda değişiklik penceresi planlama yazısındaki şablon doğrudan kullanılabilir.

Sahada sık yapılan hatalar

• Yükseltme yolunu atlamak: Ara sürüm gerektiren geçişte doğrudan hedef sürüme gitmek; bazı platformlarda bootloader uyumsuzluğu yüzünden cihaz açılmayabilir.
• Kaydedilmemiş konfigürasyon: Reload sırasında kaydedilmemiş değişikliklerin kaybolması ve oluşan sorunun yanlışlıkla güncellemeye bağlanması.
• Tek gecede tüm ağ: Pilot cihaz olmadan tüm erişim katmanını aynı gece güncellemek; ortak bir hata bütün binayı etkiler.
• SFP ve modül uyumluluğunu kontrol etmemek: Yeni sürümde üçüncü taraf optiklerin varsayılan davranışı değişmiş olabilir; port açılmaz.
• Eski imajı hemen silmek: Gözlem süresi bitmeden eski paketleri temizlemek geri dönüşü uzatır.

Yıllık firmware envanteri kontrol listesi

Bu liste yılda en az bir kez, tercihen bütçe dönemi öncesinde kurumsal ağ altyapısındaki tüm cihazlar için işletilir; güvenlik bildirimleri ise her ay gözden geçirilir.

• Her cihazın model, seri numarası, rol, mevcut sürüm ve hedef sürüm bilgisi envanterde güncel mi?
• Rol bazında altın sürüm listesi yazılı mı ve son değerlendirme tarihi belli mi?
• Altın sürümden sapan cihazlar raporlanıyor ve sapma gerekçesi kayıtlı mı?
• Her model için güvenlik desteği bitiş tarihi üreticinin güncel duyurusundan alınmış mı?
• Güvenlik desteği önümüzdeki 18 ay içinde bitecek cihazlar için değişim planı ve bütçe talebi var mı?
• Destek sözleşmeleri yazılım indirme hakkını kapsıyor ve süreleri envanterle uyumlu mu?
• Son 12 ayda yayımlanan güvenlik bildirimleri için “etkilenmiyor / geçici çözüm uygulandı / güncellendi” kararları kayıtlı mı?
• Pilot cihaz ve test prosedürü tanımlı mı?
• Konsol ve out-of-band erişim yolları her lokasyon için test edilmiş mi?

Bu döngüyü periyodik bakımın içine almak isteyen ekipler için ağ bakım, izleme ve periyodik kontrol hizmetimiz; yeni cihazı baştan doğru sürüm ve standart yapılandırmayla devreye almak için switch, router ve ağ cihazları kurulumu hizmetimiz başlangıç noktasıdır.

Sık sorulan sorular

Switch firmware’i ne sıklıkla güncellenmeli?

Sabit takvim yerine iki katmanlı model kullanın: güvenlik bildirimleri her ay değerlendirilir, olağan sürüm güncellemesi rol bazında yılda bir veya iki kez planlanır. Sizi etkileyen ve aktif istismar edilen bir açık varsa olağan döngü beklenmez.

En yeni sürüm her zaman en güvenli sürüm müdür?

Hayır. Yeni özellik dalının ilk sürümü güncel düzeltmeleri içerse de sahada az çalışmış koddur. Üreticinin önerilen veya uzun bakımlı dalında, ilgili açıkları kapatan en güncel bakım sürümü çoğu üretim ağı için daha dengeli seçimdir.

EoS ile EoL arasındaki fark nedir?

End-of-Sale, ürünün artık satılmadığı tarihtir; ürün bir süre daha yazılım ve donanım desteği alır. Destek tamamen bittiğinde ürün yaşam döngüsünün sonuna gelir. Operasyon için asıl kritik tarih güvenlik düzeltmelerinin kesildiği tarihtir; model bazında üreticinin duyurusundan okunur.

Stack’lenmiş switch’leri kesintisiz güncellemek mümkün mü?

Fiziksel stack tek kontrol düzlemidir; tipik install modu güncellemesi tüm üyeleri birlikte yeniden başlatır. Bazı platformlar sınırlı senaryolarda kesintisiz yükseltme sunar, ama destek koşulları platforma ve sürüme bağlıdır. Stack güncellemesini bakım penceresi işi olarak planlayın.