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

İlgili yazılar

Cisco VLAN Trunk Troubleshooting: VLAN Var Ama Trafik Neden Geçmiyor?

17 saat önce

Cisco 802.1X + ISE: Access Layer’da Kimlik Tabanlı Erişim Kontrolü

1 hafta önce

Cisco Port Security + IP Source Guard: Access Layer Güvenliğini Güçlendirin

2 hafta önce

Bazen bütün problem birkaç byte’tır:

MTU / MSS / Fragmentation / PMTUD ⚠️

Network troubleshooting sırasında şu tabloyla karşılaşabilirsiniz:

✅ Ping çalışıyor
✅ Routing doğru
✅ Firewall izin veriyor
✅ BGP / OSPF stabil

Ama:

❌ HTTPS session tamamlanmıyor
❌ VPN içindeki uygulamalar takılıyor
❌ Dosya transferleri kopuyor
❌ TCP retransmission artıyor
❌ Büyük paketlerde trafik duruyor

Bu durumda MTU ve MSS kontrolü kritik hale gelir.

---

1️⃣ Önce Interface ve IP MTU’yu kontrol edin

show interfaces GigabitEthernet0/0
show ip interface GigabitEthernet0/0

Standart Ethernet ortamlarında IP MTU çoğunlukla:

1500 bytes

olarak kullanılır.

Ancak aşağıdaki encapsulation’lar ek overhead oluşturur:

GRE
IPsec
GRE over IPsec
VXLAN
PPPoE
MPLS
SD-WAN encapsulation

Sonuç:

1500-byte inner packet
+
Tunnel overhead
=
Underlay MTU aşılabilir

Ve paket ya fragment olur ya da DF biti set ise drop edilir.

---

2️⃣ Path MTU’yu DF Bit ile test edin

Cisco IOS / IOS-XE üzerinde önemli ayrıntı:

ping 10.10.10.10 size 1500 df-bit

Cisco tarafında size değeri toplam IP datagram boyutudur.

Bu nedenle:

Cisco IOS/XE:
ping 10.10.10.10 size 1500 df-bit

1500-byte IP packet test eder.

Windows tarafında ise:

ping 10.10.10.10 -f -l 1472

Çünkü:

1472 ICMP payload
+ 8 byte ICMP header
+ 20 byte IPv4 header
=
1500 bytes

Linux’ta benzer test:

ping -M do -s 1472 10.10.10.10

📌 Bu ayrım önemli:

Cisco size 1500
≠
Windows/Linux payload 1500

---

3️⃣ Büyük paketten küçüğe doğru test edin

Örneğin:

ping 10.10.10.10 size 1500 df-bit

başarısızsa:

ping 10.10.10.10 size 1450 df-bit
ping 10.10.10.10 size 1400 df-bit
ping 10.10.10.10 size 1380 df-bit

şeklinde ilerleyebilirsiniz.

Daha sistematik yaklaşım:

En büyük başarılı paketi bul
↓
Path MTU'yu belirle
↓
Tunnel overhead'i hesapla
↓
Gerekirse MSS'i ayarla

---

4️⃣ Tunnel Overhead’i unutmayın

Örneğin temel GRE, pakete ek header bindirir.

Dolayısıyla:

Inner packet
+
GRE/IPsec/UDP/ESP overhead
=
Outer packet

Outer packet fiziksel interface MTU’sunu aşarsa problem oluşabilir.

Ancak özellikle IPsec’te overhead sabit tek bir sayı değildir.

Şunlara göre değişebilir:

Tunnel / transport mode
ESP algoritması
Authentication tag
Padding
NAT-T
IPv4 / IPv6 outer header
GRE kullanımı

Bu yüzden:

⚠️ “IPsec varsa MSS kesin 1360 olmalı” diye evrensel bir değer yoktur.

---

5️⃣ TCP MSS’i kontrol edin

TCP bağlantısı kurulurken SYN paketinde taraflar destekledikleri MSS — Maximum Segment Size değerini bildirir.

IPv4 TCP için basit teorik ilişki:

MSS ≈ Path MTU - IPv4 Header - TCP Header

1500-byte klasik IPv4 Ethernet için:

1500
- 20 byte IPv4
- 20 byte TCP
=
1460 MSS

Tunnel varsa kullanılabilir MSS daha küçük olabilir.

Cisco üzerinde örnek:

interface Tunnel10
 ip tcp adjust-mss 1360

Ancak:

📌 1360 yalnızca örnektir.

Doğru değer gerçek tunnel overhead ve path MTU’ya göre hesaplanmalıdır.

---

6️⃣ ip tcp adjust-mss tam olarak ne yapıyor?

Cisco:

ip tcp adjust-mss 1360

komutuyla interface üzerinden geçen TCP SYN paketlerindeki MSS option değerini sınırlar.

Mantık:

Client:
MSS 1460 kullanabilirim

Router:
Bu path için en fazla 1360 kullan

↓
TCP endpoint daha küçük segment üretir
↓
Tunnel içinde fragmentation riski azalır

Ama kritik ayrım:

MSS = TCP
MTU = IP

Dolayısıyla MSS clamping:

✅ TCP için faydalıdır.

Ama:

❌ UDP
❌ ICMP
❌ diğer IP protokolleri

için MTU problemini doğrudan çözmez.

---

7️⃣ PMTUD’yi unutmayın

Path MTU Discovery — PMTUD, path üzerindeki en küçük MTU’yu keşfetmeye çalışır.

IPv4 mantığı:

Host
↓
DF=1 packet
↓
Router
↓
Packet next-hop MTU'dan büyük
↓
DROP
↓
ICMP Destination Unreachable
Fragmentation Needed
↓
Source MSS/packet size küçültür

Problem şu:

🔥 Firewall ICMP mesajını engelliyorsa kaynak MTU’nun küçültülmesi gerektiğini öğrenemez.

Sonuç:

Küçük paketler çalışır.
Büyük paketler kaybolur.
TCP session başlar.
Ama veri transferi takılır.

Bu duruma genellikle:

PMTU Black Hole

denir.

---

8️⃣ “Ping çalışıyor ama HTTPS çalışmıyor” neden olabilir?

Normal ping varsayılan olarak küçüktür.

Örneğin küçük ICMP packet:

100 byte

path üzerinden rahatça geçebilir.

Ancak HTTPS üzerinden TCP büyük segmentler göndermeye başladığında:

1500-byte IP packet
↓
Tunnel / low-MTU path
↓
DF set
↓
Fragmentation gerekiyor
↓
ICMP engelli
↓
Packet drop
↓
Retransmission

oluşabilir.

Bu yüzden:

Ping başarılı

tek başına MTU’nun doğru olduğunu kanıtlamaz.

---

9️⃣ Packet Capture tarafında neye bakarım? 🔍

Wireshark veya SPAN/TAP capture üzerinde özellikle:

TCP Retransmission
TCP Dup ACK
TCP SYN / SYN-ACK MSS
ICMP Fragmentation Needed
DF Bit
IP Total Length
TCP Segment Length
Packet Size

alanlarını kontrol ederim.

Özellikle:

TCP SYN → MSS = ?
TCP SYN/ACK → MSS = ?

kontrolü çok değerlidir.

---

🔟 Cisco tarafında hızlı kontrol komutları

show interfaces GigabitEthernet0/0
show ip interface GigabitEthernet0/0

Tunnel:

show interfaces Tunnel10
show ip interface Tunnel10

Route:

show ip route 10.10.10.10
show ip cef 10.10.10.10 detail

DF testi:

ping 10.10.10.10 size 1500 df-bit
ping 10.10.10.10 size 1450 df-bit
ping 10.10.10.10 size 1400 df-bit

Belirli source’tan test:

ping 10.10.10.10 size 1500 df-bit source GigabitEthernet0/0

Tunnel konfigürasyonunda:

show running-config interface Tunnel10

özellikle şunlara bakarım:

ip mtu
ip tcp adjust-mss
tunnel mode
tunnel source
tunnel destination
tunnel path-mtu-discovery

---

1️⃣1️⃣ mtu, ip mtu ve MSS aynı şey değildir

Bu üç kavram sık karıştırılır.

Interface MTU

Interface/frame seviyesindeki kapasiteyle ilgilidir.

IP MTU

Interface üzerinden fragmentation olmadan taşınabilecek IP paket boyutunu belirler.

Örnek:

interface Tunnel10
 ip mtu 1400

TCP MSS

TCP payload segment boyutunu sınırlar.

interface Tunnel10
 ip tcp adjust-mss 1360

Basitleştirilmiş:

MTU
└── IP packet boyutu

MSS
└── TCP payload boyutu

---

1️⃣2️⃣ MTU problemi yalnız VPN’de görülmez

Bu problem şu ortamlarda da karşınıza çıkabilir:

GRE
IPsec
DMVPN
SD-WAN
VXLAN
PPPoE
MPLS transport
Cloud VPN
Private connectivity
Firewall tunnel
Nested virtualization
Overlay network

Özellikle overlay-underlay tasarımlarında:

Overlay MTU
<
Underlay MTU

hesabı doğru yapılmalıdır.

---

1️⃣3️⃣ IPv6 tarafında durum biraz farklıdır

IPv6’da intermediate router’lar IPv4’teki gibi paket fragmentation yapmaz.

Paket next-hop MTU için fazla büyükse router:

ICMPv6 Packet Too Big

mesajı gönderir.

Fragmentation gerekiyorsa bunu kaynak host yapar.

Bu nedenle IPv6 ağlarda ICMPv6’yi körü körüne filtrelemek çok daha ciddi problemlere yol açabilir.

---

🎯 Benim hızlı troubleshooting akışım

1. L1/L2 durumu
↓
2. Routing / CEF
↓
3. Firewall / ACL
↓
4. Interface + IP MTU
↓
5. DF-bit ile PMTU testi
↓
6. Tunnel encapsulation overhead
↓
7. TCP MSS
↓
8. PMTUD / ICMP kontrolü
↓
9. Packet Capture

Özellikle şu kombinasyonu görüyorsam:

Ping OK
+
TCP handshake OK
+
Büyük transfer FAIL
+
Retransmission yüksek

MTU / MSS / PMTUD konusu ilk şüphelilerimden biri olur.

---

🔥 Kritik mesaj:

Reachability ≠ Sağlıklı application flow

ve:

Ping çalışıyor
≠
Path MTU doğru

Network’te her problem routing veya firewall değildir.

Bazen tüm problem gerçekten birkaç byte farktan kaynaklanır. 📦⚠️

💬 Siz MTU problemi yaşadığınızda ilk olarak DF-bit + packet size testi mi yapıyorsunuz, yoksa doğrudan packet capture mı alıyorsunuz?