Bir PLC keşfedilebilir ve kısa komutlar yanıt alabilir, ancak reçete yüklemeleri veya uzak ekranlar sürekli takılıp kalabilir. Optik modülü değiştirmek veya anahtar portunun hızını artırmak sorunu çözmeyebilir. Güç, bağlantı kalitesi ve yazılımın yanı sıra kolayca gözden kaçabilen bir sınırı da kontrol edin: Bu iletişim yolu ne kadar büyük bir paket taşıyabilir? MTU hızı değil, boyutu tanımlar. MTU'yu Ethernet çerçeve uzunluğundan, jumbo çerçevelerden ve TCP segmentlerinden ayırmak, küçük paketler çalışırken büyük paketlerin neden başarısız olabildiğini açıklamaya yardımcı olur.
Sarmalamadan başlayın: Uygulama verisinin dışında birden fazla katman bulunur
Bir bilgisayardan veya denetleyiciden gelen bilgi, genellikle kabloda uygulamanın oluşturduğu biçimiyle yer almaz. Bir TCP bağlantısında uygulama verisine önce portlar ve sıra numaraları gibi taşıma bilgilerini içeren bir TCP başlığı eklenir. Ardından bir IP başlığı, paketin nereden geldiğini ve nereye gittiğini belirtir. Son olarak bir Ethernet çerçevesi, paketi yerel bağlantı üzerinden taşır. Alıcı bu katmanları ters sırayla kaldırır. Her katmanın kendi uzunluğu vardır; tek bir sayı hepsini tanımlayamaz.
Burada IP MTU, bir arayüzün iletebildiği en büyük tam IP paketini ifade eder. IP başlığını ve IP yükünü içerir, ancak dış Ethernet başlığını ve çerçeve kontrol dizisini içermez. Birçok standart Ethernet arayüzü 1500 baytlık bir IP MTU kullanır, ancak bu evrensel bir ayar değildir. Bir VLAN etiketi, dış çerçeveye bilgi ekler. Bir kılavuzdaki maksimum çerçeve uzunluğunun etiketleri ve kontrol dizisini içerip içermediği, o kılavuzun tanımına bağlıdır. Bir cihazın büyük çerçeveleri desteklediğinin belirtilmesi, kesin yapılandırmasını belirlemek için yeterli değildir.
MSS ve jumbo çerçeveler: Biri TCP verisini sınırlar, diğeri çerçeve kapasitesini artırır
MSS, yani maksimum segment boyutu, tek bir TCP segmentinde taşınan uygulama verisi bölümünü sınırlar. MTU'yu paketlenmiş bir kolinin boyutu, MSS'yi ise içindeki içerik olarak düşünün. Bir TCP bağlantısı başladığında her alıcı, almaya hazır olduğu MSS değerini bildirir. Gönderici kendi arayüzünü ve yolu da hesaba katmalıdır. Yalnızca iki uç noktada bir sayı seçmek, rotanın tamamının bu boyutu taşıyabileceğini garanti etmez. TCP seçenekleri, IP sürümü ve ek kapsülleme, kullanılabilir alanı etkileyebilir.
Jumbo çerçeveler genellikle geleneksel Ethernet çerçeve boyutunu aşar. Belirli miktarda veriyi taşımak için gereken çerçeve sayısını azaltabilirler, ancak ek port bant genişliği oluşturmaz veya daha hızlı kontrol yanıtlarını garanti etmezler. Uç nokta ağ bağdaştırıcıları, anahtar portları, yönlendirici arayüzleri ve aradaki ekipmanın tümü ilgili gereksinimleri karşılamalıdır. Bir anahtarda jumbo çerçeveleri etkinleştirmek, bunları desteklemeyen bir PLC'nin veya uzak cihazın kabul etmesini sağlayamaz. Kısa kontrol mesajları, çerçeve sınırının artırılmasından pratikte hiçbir fayda görmeyebilir.
Yalnızca uç noktaları değil, rotanın en dar bölümünü kontrol edin
Geniş bir yoldan yola çıkıp daha sonra dar bir köprüye ulaşan bir teslimat aracı düşünün. Büyük bir koli başlangıç noktasında sığabilir, ancak o köprüden geçmesine izin verilmeyebilir. Yol MTU'su, göndericiden alıcıya uzanan rota üzerindeki bağlantıların getirdiği boyut sınırıdır. Yönlendirme, uzaktan erişim veya bir tünel, bu sınırı yerel LAN sınırından daha küçük hâle getirebilir. Bir yedek rota veya yeni eklenen bir güvenlik ağ geçidi de daha önce sorunsuz çalışan boyutu değiştirebilir.
Katman 2 anahtarı esas olarak Ethernet çerçevelerini iletir. Bir çerçeve kabul sınırını aşarsa anahtar onu düşürebilir ve ilgili sayacı artırabilir. İçindeki IP paketini daha küçük parçalara bölerek yardımcı olmaz. IP parçalama, IP katmanının bir işlevidir. Anahtarın çerçeve uzunluğu ayarını, yönlendiricinin IP MTU'su ile karıştırmayın. Yol üzerindeki gerçek ekipmanı ve arayüzleri çizin; yerel anahtarlamayı, alt ağlar arasındaki yönlendirmeyi ve tünel kapsüllemesini birbirinden ayırın. Yalnızca iki uç noktanın yapılandırma ekranlarını karşılaştırmak yeterli değildir.
IPv4 boyutu aşan bir paketi nasıl bildirir ve IPv6 bundan nasıl farklıdır?
Geleneksel IPv4 yol MTU keşfinde gönderici, DF yani Parçalama bayrağını ayarlar. Bir yönlendiricinin bu paketi daha küçük MTU'lu bir bağlantıya iletmesi gerekiyorsa ve paketi parçalayamıyorsa, yönlendirici paketi düşürür ve kaynağa parçalama gerektiğini belirten bir ICMP hatası gönderir. Kaynak, bu geri bildirimi kullanarak söz konusu yol için paket boyutunu azaltır ve yeniden dener. ICMP, bir teslimat ret bildirimi gibidir: Bir uygulama komutu değildir, ancak uygulama iletişiminin sürmesine yardımcı olabilir.
Bu gerekli geri bildirim filtrelenirse gönderici tekrarlanan zaman aşımlarıyla karşılaşabilir. Kısa komutlar çalışırken büyük bir aktarım çok az ilerleme kaydedebilir. Gerçek sistemler başka yoklama veya alternatif mekanizmalar da kullanabilir; dolayısıyla bu, filtrelenen her hatanın kaçınılmaz olarak kalıcı bir takılmaya yol açtığı anlamına gelmez. IPv4 parçalamaya izin verildiğinde bir yönlendirici paketi parçalayabilir ve alıcı onu yeniden birleştirir. IPv6 yönlendiricileri aktarım sırasında bu parçalamayı yapmaz; Packet Too Big mesajı kaynağa ayarlama yapmasını bildirir. Bu mekanizmalar tek bir evrensel düzeltme prosedürü olarak birleştirilmemelidir.
Tünel başka bir sarmalama ekler; dolayısıyla daha önce uygun olan bir paket büyüyebilir
Bir uzaktan bakım bağlantısı, mevcut bir paketi yeni bir dış kapsüllemenin içine yerleştirebilir. Bu, zaten paketlenmiş bir kutuyu bir nakliye sandığına koymaya benzer: Yol, toplam boyutu taşımalıdır. Uygulama verisi değişmemiştir, ancak dış rota üzerinde görülen paket daha büyüktür. Ekipman, tünelin etkin MTU'sunu ve gönderim politikasını doğru şekilde hesaba katmazsa yerel erişim çalışmaya devam ederken yalnızca uzak yolda hatalar görülebilir.
Her VPN veya tünel için aynı sabit bayt sayısını çıkarmayın. Protokol, şifreleme yöntemi ve kapsülleme katmanlarının sayısı ek yükü etkiler; kullanılan uygulamanın ayrıntılarına başvurun. TCP MSS ayarını değiştirmek, belirli bir yoldaki TCP segment boyutlarını azaltabilir, ancak tüm UDP trafiğini otomatik olarak ele almaz veya çerçeve kapasitesi kontrollerinin yerini tutmaz. Güvenlik cihazının özgün yapılandırmasını koruyun, etkilenen trafiği belirleyin ve gerekli hata geri bildirimini doğrulayın. Sırf büyük paketlerin geçmesini sağlamak için bir güvenlik politikasının tamamını devre dışı bırakmayın.
Sorun giderme: Test uzunluğunu belirli bir gerekçeyle değiştirin
Bir bakım zaman aralığında, çalışan küçük paketler için bir referans durumu kaydedin, ardından test uzunluğunu kademeli olarak artırın. Tutarlı bir sınıra yakın noktalarda oluşan hataları arayın. Aracın uygulama yükünü mü, IP paket uzunluğunu mu yoksa tam çerçeve uzunluğunu mu gösterdiğini belirleyin; komut parametreleri farklı işletim sistemlerinde aynı anlama gelmez. Tek bir standart ping işleminin başarılı olması, büyük çerçevelerin yolun tamamında çalıştığını kanıtlamaz. Üretimdeki bir kontrol bağlantısında sınırsız stres testleri yapmayın.
Gönderici, alıcı ve ara cihazlardaki bulguları karşılaştırın. İstek gönderildi mi? Uzunlukla ilgili bir hata geri döndü mü? Bir anahtar portu, boyutu aşan çerçeve düşürmelerini saydı mı? Bir yönlendirici veya tünel, boyutu aşan bir paket bildirdi mi? Bir ana bilgisayarda alınan paket kaydındaki olağan dışı büyüklükteki bir paket, ağ bağdaştırıcısının işlem yükünü devralmasının sonucu da olabilir; fiziksel hat üzerinde aynı boyutta görünmeyebilir. Gerektiğinde uygun bir harici gözlem noktası kullanın. Tek başına bir kayıp sayacı, nedenin MTU olduğunu kanıtlayamaz: Tıkanıklık, kablo hataları ve uç nokta işleme arızaları da dikkate alınmalıdır.
Testten önce, aracın uzunluk değerinin hangi katmanı tanımladığını belgeleyin. Bazı araçlar test verisi uzunluğunu kabul eder, bazıları tam bir IP paketini bildirir, diğerleri ise hat üzerindeki çerçeveyi gösterir. Bu değerleri karıştırmak, ekipmanın tutarlı davranışını çelişkili gösterebilir. Aracı, uzunluk tanımını, parçalama ayarını ve yönü kaydedin. Sonucun nedeninin açık olması için her seferinde tek bir koşulu değiştirin. Bağdaştırıcıyı, tüneli ve anahtarı birlikte değiştirmek, asıl darboğazı gizlerken hizmeti geçici olarak geri getirebilir.
Boyut sınırını endüstriyel kabul testlerinin bir parçası hâline getirin
FCTEL tarafından yönetilebilir endüstriyel anahtarlar için yayımlanan dokümantasyon, arayüzleri ve ağ koşullarını kontrol etmek için bir başlangıç noktasıdır. Belirli bir modelin belirli bir jumbo çerçeve boyutunu destekleyip desteklemediği ve yapılandırmanın port bazında mı yoksa genel mi olduğu yine de o modelin kılavuzundan veya doğrulanmış dokümantasyonundan kontrol edilmelidir. Gigabit hız ve yönetim yeteneği tek başına jumbo çerçeve desteğini kanıtlamaz. Bakır ve optik portlar farklı fiziksel ortamlar kullanır; bakırın fiberle değiştirilmesi, çerçeve uzunluğu veya IP paket sınırlarını ortadan kaldırmaz.
Bir kabul kaydı; uç nokta MTU'larını, her cihazın maksimum çerçeve uzunluğu tanımını, yönlendirme ve tünel kısıtlarını, her iki yöndeki test koşullarını ve hatanın oluştuğu noktayı listeleyebilir. Uygulama büyük çerçeveler gerektiriyorsa rotanın her bölümünü doğrulayın. Gerektirmiyorsa test edilmiş geleneksel bir yapılandırmanın bakımı çoğu zaman daha kolaydır. Üç soruyu yanıtlayın: Hangi boyut geçebilir, sınırın üzerinde ne olur ve yol değiştiğinde uygulama toparlanabilir mi? Bu çizimlerdeki boyutlar açıklayıcı örneklerdir; FCTEL ürün özellikleri veya saha ölçümleri değildir.
Teknik kaynaklar: RFC 1191: IPv4 yol MTU keşfi; RFC 8201: IPv6 yol MTU keşfi; Cisco: Parçalama, MTU, MSS ve tünel davranışı; Cisco: Bir anahtar MTU sorun giderme örneği. İlgili FCTEL kaynakları: Teknik Makaleler ve FCTELE FCM-G24FG4 yönetilebilir 24 portlu Gigabit Ethernet + 4 portlu combo anahtar belgeleri.
