Üretimde en zor teşhis edilen incident sınıflarından biri şudur: sistem genel olarak ayakta görünür, ama kullanıcıların bir kısmı çalışırken bir kısmı çalışmaz. Özellikle:
- TLS handshake bazı istemcilerde takılır,
- API çağrıları küçük payload ile çalışır ama büyük payload ile time-out olur,
- aynı endpoint bazı ağlardan iyi, bazı ağlardan kötü çalışır.
Bu tablo çoğu zaman “uygulama bug’ı” gibi okunur. Oysa çok sık bir root-cause vardır: MTU/PMTUD blackhole.
Kavram: PMTUD neyi çözer?
Path MTU Discovery (PMTUD), iki uç arasındaki yol üzerinde “maksimum iletilebilir paket boyutunu” (MTU) bulmak için kullanılır. Kırılma genelde şu sebeple olur:
- Uç, DF (Don’t Fragment) bit’iyle büyük paket gönderir
- Yol üzerindeki bir cihaz bu paketi iletemez (daha küçük MTU gerekir)
- Cihaz, geri dönüşte “fragmentation needed” benzeri ICMP mesajı göndermelidir
- Bu ICMP bloklanırsa, uç MTU’yu düşüremez → paketler sessizce düşer → blackhole
En sık tetikleyen senaryolar
Sahada en çok şu geçişlerde karşımıza çıkar:
- IPsec/GRE tünelleri (overlay header + şifreleme overhead)
- SD-WAN/MPLS edge geçişleri
- Cloud interconnect / transit gateway / firewall zone geçişleri
- Jumbo frame kullanılan segmentler ile 1500 MTU segmentlerin karışması
- “MSS clamp” yapılan ama tüm uçları kapsamadığı için yarım kalan düzeltmeler
Incident triage: 15 dakikalık hızlı teşhis
Amaç: “problem uygulama mı, yol MTU/PMTUD mi?” sorusunu hızlı cevaplamak.
1) Semptomu paket boyutuna bağla
- Küçük payload çalışıyor, büyük payload bozuluyorsa MTU ihtimali yükselir.
- HTTP/2 veya gRPC gibi protokollerde de benzer tablo çıkabilir; yine paket boyutu ilişkisini ara.
2) DF ile ping (Linux/macOS/Windows farkına dikkat)
Karşı uç (veya problemli hop’a yakın bir test endpoint) için DF testini uygula. Örnek (Linux):
ping -M do -s 1472 <hedef-ip> -c 3
ping -M do -s 1400 <hedef-ip> -c 31472payload + 28 byte IP/ICMP header ≈ 1500 MTU- Büyük paket fail, küçük paket ok ise “yolda daha küçük MTU” sinyali alırsın.
3) tracepath / traceroute ile “pmtu” ipucu
tracepath <hedef-ip> | head -n 20pmtu satırı veya “too big” benzeri mesajlar görürsen daha da güçlenir.
4) Uygulama tarafında TCP sinyali: retrans + stalls
Eğer erişimin varsa, problemli host üzerinde kısa bir yakalama al:
sudo tcpdump -nn -i any 'host <hedef-ip> and tcp' -c 200Şunlara bak:
- Aynı segmentin tekrar tekrar gönderilmesi (retransmission)
- SYN/SYN-ACK var ama sonra handshake ilerlemiyor (MSS/MTU kırığı olabilir)
Mitigation: hızlı, güvenli ilk hamleler
Incident anında “en az riskli” müdahale çoğu zaman şunlardır (ortama göre):
1) TCP MSS clamping (geçici rahatlatma)
Tünel veya edge firewall üzerinde MSS clamp yapmak, PMTUD kırığı varken servisleri toparlayabilir. Ama bu bir “kapat ve unut” çözümü değildir; root-cause’u maskeleyebilir.
2) Tünel/overlay MTU’yu doğru ayarla
IPsec/GRE gibi kapsülleme ekleyen katmanlarda efektif MTU düşer. Tünel arayüz MTU’sunu ve uçların PMTUD davranışını birlikte düşün.
3) PMTUD için gerekli ICMP’yi allowlist et
Hedef, ICMP’yi tamamen açmak değil; PMTUD için gerekli tip/kodları kontrollü geçirmek ve loglamak olmalı.
Root-cause kapanış: kalıcı önlemler
1) Change checklist’e MTU testini ekle
Özellikle şu değişikliklerde:
- yeni tünel/overlay
- yeni güvenlik duvarı geçişi
- farklı provider/POP taşıma
- jumbo frame devreye alma
“Büyük paket geçiyor mu?” testini standartlaştır.
2) Gözlem: MTU kaynaklı incident’i metrikle yakala
İyi sinyaller:
- TCP retransmission oranı artışı
- SYN tamamlanıyor ama uygulama katmanı handshake (TLS) tamamlanmıyor
- belirli path/segmentlerde belirgin latency + time-out artışı
3) Dokümantasyon: “MTU gerçekleri”ni görünür kıl
Üretimde MTU, çoğu zaman kimsenin sahiplenmediği bir “varsayım”dır. Segment bazında efektif MTU (özellikle tünel/şifreleme sonrası) yazılı olsun.
Sonuç
MTU/PMTUD blackhole, uygulama bug’ı gibi görünerek incident süresini uzatır. Doğru teşhis için semptomu paket boyutuna bağla; hızlı DF testleriyle olasılığı daralt; geçici mitigation’ı (MSS clamp) kalıcı çözüme (doğru MTU + doğru ICMP allowlist + change testleri) bağla. Operasyonel gerçeklikte başarı; “çok teknik anlatı” değil, tekrarlanabilir runbook ve kapanış disiplinidir.