Gigabit Ağına Yükseltme - Jumbo Çerçeveleri Etkinleştirme


21

SOHO ağımı gigabit'e (10/100 den) yükseltmeye başlamak istiyorum ve biraz Jumbo Frames duydum.

Jumbo Çerçeveleri bir ağda uygulamanın en iyi yolu ne olabilir? Düzgün çalışabilmesi için anlatabileceğimden, ağdaki tüm ağ donanımları Jumbo Çerçeveleri desteklemelidir. Bu doğru mu?

GB ethernet ile güncellenemeyen özel bir donanıma (ör. Ağ yazıcısı) sahip olursam bu Jumbo Çerçeveleri etkinleştirmemi engeller mi?

Jumbo Çerçeveleri etkinleştiren bazı kazanımlar nelerdir?

Yanıtlar:


20

İlk olarak, jumbo frame ethernet'in ne olduğunu açıklamak en iyisi olabilir. Ethernet bir katman 2 ağ teknolojisidir ve Protokol Veri Birimi (PDU) bir çerçevedir. Başvuru için, bir L3PDU (IP katmanı) bir pakettir ve bir L4PDU (tcp / udp) bir segmenttir.

Bir ethernet çerçevesi (birkaç tür ethernet vardır, ancak burada genelleyebiliriz) bir veri kaynağını (diğer şeylerin yanı sıra bir kaynak MAC, bir hedef MAC, bir 802.1q VLAN etiketi, vb. İçeren) içerir. çerçeve ve çerçevenin başarılı iletimini onaylamak için kullanılan bir CRC sağlama toplamı.

Orijinal ethernet, 1500 bayt (veya muhtemelen 1518, bakmak zorunda) olarak bir çerçeve boyutu (başlık ve sağlama toplamı dahil tüm çerçevedeki verilerin değeri) belirtti. Bu sayı, bir kerede gönderilecek veri miktarı ile aktarımın başarısız olması veya çarpışması ve yeniden iletilmesi gerekmesi arasında bir denge oluşturdu. Hızlı, tam çift yönlü LAN'ların ortaya çıkmasıyla insanlar, ethernet çerçeve boyutunu artırarak performansın artırılabileceğini fark ettiler. Genellikle jumbo çerçevelerin boyutu kare başına 9000 bayttır;

Tüm elemanların jumbo çerçeveli ethernet almayı beklediği kaya gibi sağlam, tam çift yönlü LAN (veya VLAN), aslında performansı artırıyor. Bu senaryodaki sorun, onu beklemeyen bir ağ öğesi veya sonlandırma aygıtı tanıtmanızdır. En iyi durumda, paketlerin kaybolması nedeniyle performansın düşmesine neden olur çünkü alıcı cihazlar bir çerçevede sadece 1518 byte bekliyorlar.

Şimdi özel sorularınız için:

Jumbo Çerçeveleri bir ağda uygulamanın en iyi yolu ne olabilir?

Bu öznel bir soru. İş yerimde, sadece tüm değişkeni kontrol altında tuttuğumuzu bildiğimiz ve yardımcı olacağını biliyorduk. Bunu yapmak için, yalnızca belirli cihazların ikinci NIC'leri üzerinden erişebileceği özel bir "özel" kanala uyguladık. Özellikle, dosya sunucularımızın ve uygulama sunucularımızın ikinci NIC'ini bu yeni VLAN'a yerleştirdik ve daha sonra bu VLAN'da kullanılan IP şemasına yapılan tüm referansları değiştirdik. Bu da, (bir masaüstü makineyi bu VLAN'a bağlayacak hiç kimse yok) en fazla faydalanacağını bildiğimiz alanı (altyapımızdaki en yüksek kullanım veri bağlantıları) hedeflememizi sağlar. Bu, riski en aza indirirken kazancı maksimize eder.

Daha spesifik olarak, ağ tarafında (IOS kullanarak), jumbo çerçeve cihazlarına adanmış VLAN'lar yaptık, sonra vlan tanımlarına "mtu 9000" ekledik. Bu ağı kullanacak olan anahtar üzerindeki her arayüz "switchport access vlan 11" gibi bir şey kullanarak bu vlana koyuldu. Linux makinelerinde (standart ağa bağlı eth0 ve jumbo çerçeve ağına bağlı eth1) / etc / sysconfig / network-scripts / ifcfg-eth1'e "MTU = 9000" i ekledik. Çünkü bu paketleri asla yönlendirmeyiz (doğrudan jumbo çerçeveye VLAN'a bağlı olmayan herhangi bir şeyin jumbo çerçeveye VLAN'da bir NIC ile konuşması imkansızdır) bir yönlendirici yapılandırması için endişelenmemiz gerekmedi.

Düzgün çalışabilmesi için anlatabileceğimden, ağdaki tüm ağ donanımları Jumbo Çerçeveleri desteklemelidir. Bu doğru mu?

Evet oldukça. Tüm ağ "istemcileri" (bunun anlamı sunucular / masaüstü bilgisayarlar / IPKVM'ler / IP çevre monitörleri, vb.) Da konuşmalı veya yukarıda da belirtildiği gibi, yarıya erişilebilen çok sayıda makineye sahip olacaksınız (ping yapacaklar ve herhangi bir 1500 bayttan daha az olan L3 veya L4PDU başarılı olur; örneğin, posta sunucunuz ping yapar ve küçük bir sınama iletisi olacak olanı elden teslim edersiniz. posta (çerçeve boyutu> 1500 byte itti excel eki olan) gizemli bir şekilde başarısız olur.

GB ethernet ile güncellenemeyen özel bir donanıma (ör. Ağ yazıcısı) sahip olursam bu Jumbo Çerçeveleri etkinleştirmemi engeller mi?

Eğer durum buysa, yapacağım şey şu: (bunun üstesinden gelebilecek ağ donanımını varsayarsak):

  • biri jumbo çerçeveli diğeri diğeri olmadan iki VLAN oluşturun
  • tüm ağ cihazlarınızı bir vlana veya diğerine atayın
  • yönlendiricinizde ve anahtarlarda, jumbo frame vlan'ı uygulayın ve ağ istemcilerinde kare boyutunu değiştirin.

Bu, artık ağınızda düz bir L2 topolojisine sahip olmayacağınız anlamına gelir. Örneğin, jumbo-frame etkin sunucunuzdan, jumbo olmayan frame yazıcınıza yazdırmak istiyorsanız, paketlerin yönlendirilmesi gerekir (yönlendiriciniz üzerinden seyahat edin, çerçeveler daha geleneksel bir boyuta yeniden yazılır ve daha sonra diğer VLAN üzerinde yazıcı). Bu, jumbo şasi ve jumbo olmayan şasi makineleriniz arasındaki iletişimin öncekinden biraz daha zayıf olacağı, ancak jumbro şasi VLAN'ındaki tüm cihazlar arasındaki veri aktarım hızlarının daha iyi olacağı anlamına gelir. Bu gerçekten sadece bir yargılama çağrısı.

Jumbo Çerçeveleri etkinleştiren bazı kazanımlar nelerdir?

Umarım yukarıda kaplı. İyi şanslar!


Gerçekten o kadar kötü mü? İnternette, yol MTU keşfi, yol boyunca bazı yönlendiricilerin yalnızca 500 bayt geçip geçemeyeceğini belirler ve buna göre ayarlar. LAN'da işe yaramıyor mu?
joeforker

1
Her iki uç nokta da aynı çarpışma alanı içindeyse işe yaramaz. Bunun nedeni, gönderen birimin, alanın jumbo çerçevelerinin etkin olup olmadığını belirlemesinin bir yolu olmamasıdır. Alıcı sistem jumbo çerçevelerini etkinleştirmediyse, paket sessizce bırakılır. Aralarında yönlendirici bulunmadığından, MTU bulma yolu da çalışmaz. Son yönlendiricinin giden arabiriminde jumbo çerçevelerin etkinleştirilmiş olması ve alıcı uç nokta arabiriminin etkin olmaması durumunda MTU keşfi yolunun da başarısız olabileceğine inanıyorum.
Akış

11

Sen bulabilirsiniz Jeff Atwood yazı Jumbo Çerçeveler bilgilendirici üzerinde.

Gönderinin Önemli Noktaları:

  • % 20 Performans Artırma
  • Büyük bir çerçevenin sağlam kalması için, geçtiği her cihazın bu çerçeve boyutunu desteklemesi gerekir
  • Jumbo Çerçeveleri desteklemeyen anahtarlar onları bırakacak

5

Paketlerin maksimum boyutunu kontrol etmek ve bunu Jumbo Frames ayarlarınızla karşılaştırmak için ping.exe'yi kullanabilirsiniz.

ping -l 4096 -f server

-L tarafından kullanılan paket boyutunu ayarlayın ve DO_ NOT_FRAGMENT bayrağını ayarlamak için -f öğesini kullanın. Maksimum paket boyutunuza ulaştığınızda, "Paketin parçalanması gerekiyor, ancak DF seti gerekiyor" mesajı alırsınız.

Jumbo Çerçeveler işe yarayıp yaramadığına dair bir gösterge verecektir.


3

Evet, her şey Jumbo Çerçeveleri desteklemelidir - belirteç halkası ve ethernet arasında geçiş yapma gibi davranın. Tek fark, bazı cihazların kısa bir süre için veya aralıklı olarak hala çalışıyor gibi görünmesidir - bu, büyük bir ağda hangi cihazları yeniden yapılandırdığınızı takip etmiyorsanız (yani 2 hafta sonra Bazı kullanıcılardan odacıklarının arkasına "hemen şimdi" çalışmayı bırakan bir yazıcıyla sorun bildirildi). Aynı şey yeni şeyler için de geçerlidir; ilk açılışın ötesinde çalışmadıklarında destek aramalarını önlemek için yeni aygıtları ve jumbo çerçeveleri olan bilgisayarları yeniden yapılandırmak için bir prosedür ayarlamanız gerekir.


1

Linux'ta çalışmak için aşağıdakileri buldum: Vlans etiketli kullanıyorsanız, temel aygıt için mtu'yu (örn. Eth1) jumbo çerçeve boyutuna ayarlayın. Jumbo çerçevelerini destekleyen tüm vlanslar aynı mtu'yu alırlar, orijinali ile kalmayan vlanslar, en sık 1500.

Aslında, jumbo konuşmacıları ve anahtarlamayı etkin kılan vlanslar, yerel vlan arayüzüne, vlandaki mtu baz arayüzünkinden daha küçük olsa bile gönderebilecektir.

Ayrıca Linux'ta test edilecek komut şudur: ping -s 4096 -M do

-s boyutu, -M "parçalanma" diyor. Yerel mtu'yu aşarsanız, bir hata ile karşılaşırsınız. Uzaktaki mtu'yu aşarsanız hiçbir şey geri alamazsınız.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.