1 puan yazan GN⁺ 2024-07-05 | 1 yorum | WhatsApp'ta paylaş
  • Tüketici yönlendiricilerinin içindeki yapıya benzer şekilde anahtar çipinin Linux tarafından doğrudan kontrol edildiği bir düzeni yeniden oluşturmak için RTL8367S tabanlı bir gigabit switch PCB’si tasarlandı ve DSA/switchdev’e bağlandı
  • Seçilen RTL8367S, 5 portunda yerleşik PHY bulunan 7 portlu bir gigabit switch çipidir; özel bir CPU portu yerine port 0, ağ kablosuyla Linux kartının Ethernet’ine bağlandı
  • Donanım yapım sürecinde güç hatları 3.3V ve 1.1V olarak sadeleştirildi; önyükleme ayar pinleri, EEPROM, SPI flash ve seri port gibi yapılandırma yolları denendi
  • Linux bağlantısı için PINE64 A64-lts kartı, özel kernel seçenekleri ve Device Tree değişiklikleri gerekti; önyüklemeden sonra eth0 altında lan1~lan4 yerel ağ arayüzleri gibi göründü
  • Bu yöntem Linux bridge ve ethtool gibi mevcut araçlarla iyi uyum sağlıyor; ancak sıradan PC’lerde, sunucularda veya USB ağ arayüzlerinde Device Tree ve GPIO kısıtları nedeniyle doğrudan kullanımı zor

Yönetilebilir switch’ler ve Linux DSA mimarisi

  • Tipik bir yönetilebilir switch, web arayüzü üzerinden ayarların değiştirilmesine ve port durumunun kontrol edilmesine olanak tanır; daha pahalı cihazlar telnet veya seri konsol gibi ek arayüzler de sunar
  • Tüketici yönlendiricilerinin içindeki switch de ayrı bir yönetilebilir switch kategorisi olarak görülebilir
    • Yönlendirici küçük bir Linux cihazıdır ve içinde bir switch çipi bulunur
    • Bir veya daha fazla port CPU’ya dahili olarak bağlanır, kalanlar ise fiziksel portlar olarak dışarı açılır
  • Linux’un DSA ve switchdev alt sistemleri kullanıldığında, switch’e bağlı portlar gerçekten “yerel” ağ portları gibi davranır
  • Yönlendirici SoC’si ile switch arasında SGMII veya RGMII gibi bir bağlantı ve SMI veya MDIO gibi bir yönetim veri yolu gerekir
  • Hazır, standart switch’lerde gerekli çip bağlantıları dışarıya çıkarılmadığı için bu yöntemle kontrol etmek zordur

RTL8367S tabanlı switch kartı yapımı

  • Kendi yaptığı gigabit switch, Realtek RTL8367S çipini kullanıyor
    • Yaygın kullanılan 5 portlu bir gigabit switch çipidir
    • Aslında 7 portlu bir yapıya sahiptir; 5 portta PHY yerleşiktir, 2 port ise CPU bağlantısı içindir
  • Veri sayfası yalnızca asgari bilgi sunduğundan, benzer Realtek çipleri kullanan cihazların şemaları ve Ethernet tasarım dokümanlarıyla birlikte referans alındı
  • Başta yaklaşık 7 güç ağı gerekiyor gibi görünse de, voltaj aralıkları çakışan ağlar birleştirilerek yalnızca 3.3V ve 1.1V regülatörleri kullanılan bir yapı mümkün oldu
  • Linux switchdev, CPU bağlantısının mutlaka özel CPU portu olmasını gerektirmediği için bu tasarımda port 0 kabloyla Linux kartına bağlandı
    • switchdev sürücüsü açısından arada Ethernet PHY yokmuş gibi görünür

Switch çipi yapılandırması ve PCB deneme-yanılmaları

  • RTL8367S’te birden fazla yapılandırma yolu bulunuyor; ancak veri sayfası tek başına, sıradan bir dumb switch gibi çalışması için gereken asgari yapılandırmayı anlamayı zorlaştırıyor
    • Başlangıçta okunan 8 pin, port LED pinleriyle paylaşılır
    • i2c veri yolu EEPROM çipi bağlamak için kullanılabilir, ancak gerekli SMI veri yoluyla pinleri paylaşır
    • SPI veri yolu, yapılandırma register’larını veya yerleşik 8051 çekirdeği firmware’ini saklamak üzere NOR flash bağlamak için kullanılabilir
    • Seri portun, 8051 firmware’i olmadan çalışmayacağı değerlendirildi
  • İlk kart, doğrudan sipariş edildikten sonra lehim bağlantıları değiştirilerek çalışma koşullarını bulma yaklaşımıyla ele alındı
    • Flash çipi footprint’i eklendi, ancak sonuçta gerekmedi
    • Yapılandırma pinlerine lehim jumper’ları eklendi
    • LED’leri yapılandırılabilir yapmak zor olduğu için dahil edilmedi
  • Gigabit Ethernet tasarım dokümanları empedans kontrolü ve hassas uzunluk eşleştirmesini vurgulasa da, düşük maliyetli gerçek switch’lerin tasarımları bu kadar katı görünmüyordu
  • Daha önemli görülen kısım, ağ çiftleri arasındaki skew eşleştirmesiydi
    • 4 ağ çiftinin toplam uzunluğunu birbirine eşleştirmenin yararlı olmadığı değerlendirildi
    • Ağ kablosunun içinde de 4 çiftin büküm oranları farklı olduğundan uzunlukları zaten oldukça farklıdır
  • İlk kart revizyonunda, switch tarafındaki transformatör center tap’lerini toprağa referanslayan kapasitör uygulaması hatalı olduğundan Ethernet çalışmadı
    • Testte küçük bir trace kesilerek toprak kısa devresi ayrıldı
    • Test düzeninde center tap’ler boşta kalsa da çalıştı
    • Nihai tasarıma ilgili kapasitör eklendi

Tamamlanan switch ve Linux bağlantısı

  • Tamamlanan kart, biraz alışılmadık biçimde bir gigabit switch
    • 4 port tek bir yöne bakıyor
    • 1 port karşı yöne bakıyor ve Linux kart bağlantısı için kullanılıyor
    • Güç 2.54mm pin header üzerinden sağlanıyor
    • DuPont kablo olmadan güç verebilmek için USB Type-C konnektör footprint’i de eklendi
  • Test için Linux kartı olarak PINE64 A64-lts seçildi
    • Konnektör konumları istenen yerleşime kabaca uyuyordu
    • Device Tree değişikliği gerektiği için x86 olmayan bir platform önemliydi
  • Kernel, switch ile ilgili modüller genelde etkin olmadığı için yeniden derlendi
    • CONFIG_NET_DSA: Distributed Switch Architecture
    • CONFIG_NET_DSA_TAG_RTL8_4: Realtek switch çipi port etiketleme
    • CONFIG_NET_SWITCHDEV: ağ switch’i sürücü sistemi
    • CONFIG_NET_DSA_REALTEK, CONFIG_NET_DSA_REALTEK_SMI, CONFIG_NET_DSA_REALTEK_RTL8365MB: gerçek switch çipi sürücüsü
  • Device Tree overlay’ini U-Boot ile yüklemek yerine A64-lts kartının Device Tree’si doğrudan yamalandı
    • Sürücü, realtek,rtl8365rb uyumluluk dizgesiyle yüklendi
    • Bu sürücü, kullanılan RTL8367S dahil olmak üzere birden fazla Realtek switch çipini destekler
    • Doküman örneğindeki CPU port tanımı kaldırıldı ve 5 genel switch portu tanımlandı
  • port@0, arkaya bakan porttur ve A64-lts’in &emac arayüzüne bağlanır
    • Diğer portlar switch çipi içindeki ilgili PHY’lere bağlanır
    • Device Tree’nin üst kısmında SDA/SCL ve Reset’e bağlanan 3 GPIO tanımlanır

Linux ağ araçları ve kısıtlar

  • Önyüklemeden sonra Linux’ta normal eth0 cihazıyla birlikte Device Tree’de tanımlanan switch port arayüzleri görünür
    • lan1@eth0
    • lan2@eth0
    • lan3@eth0
    • lan4@eth0
  • Gerçekten çalıştırmak için ip link set eth0 up komutunun ve her bir lan arayüzünün ayağa kaldırılması gerekir
  • Standart Linux ağ araçlarıyla birleşimi doğal hissettirir
    • Birden çok lan portu Linux bridge’e eklenirse switchdev, bu port köprülemesini switch çipinin içinde işler
    • Linux’un bu trafiği doğrudan iletmesi gerekmez
    • ethtool lan3 ile link bilgileri görülebilir
    • ethtool -S lan3, switch’in tamamen işlediği paketler dahil standart durum bilgilerini döndürür
  • Ancak genel ortamlarda kullanmak için ciddi kısıtlar vardır
    • Ya doğrudan bir ağ switch’i yapmak ya da mevcut bir switch’i açıp gerekli bağlantıları bulmak gerekir
    • Sıradan PC’ler veya sunucular Device Tree tabanlı yapılandırmaya sahip değildir ve kernel’in kontrol ettiği GPIO pinleri de genelde kullanılamaz
    • USB ağ arayüzlerinde conduit port olarak belirtilecek bir Device Tree node handle’ı olmadığından bu yöntemde kullanılması zordur
  • Bazı kısıtlar aşılabilir olabilir; ancak GPIO’yu dışarı veren özel USB cihazları veya ARM cihazı olmayan ortamlarda switchdev’i yükleme yöntemi için daha fazla dokümantasyon gerekir

1 yorum

 
GN⁺ 2024-07-05
Hacker News yorumları
  • “Ağ anahtarı basit bir cihazdır; paketler girer ve çıkar, neyse ki insanlar bunu karmaşıklaştırmanın bir yolunu bulup yönetilebilir switchi icat etti” diye de bakılabilir; ancak pahalı switch’lerin içinde epey gelişmiş ASIC’ler bulunur.
    Örneğin eski bir çift Dell OS9 switch, 48 adet 10Gb/s port ve 4 adet 40Gb/s QSFP+ optik porta sahip eski tip yığınlanabilir cihazlardır; tek bir switch en fazla 1.28Tb/s işleyebilir.
    Bugünlerde KDV dahil yaklaşık £1800’a bulunabiliyor ve neredeyse sonsuza kadar kullanılabiliyor.
    Bu tür denemeler güzel, ama Netgear gibi yerlerin tüm portlarında PoE olan 8 portlu 1Gb switch’i yaklaşık £125’a sattığını da hesaba katmak gerekir.
    Projenin ekonomisine bakarken zamanı saat başına £20~50 olarak hesaplarsanız hazır ürün daha mantıklı olabilir; ama amaç projenin kendisiyse fiyatı dert etmeye gerek yok.
    (1) https://i.dell.com/sites/doccontent/shared-content/data-shee...
    (2) https://www.etb-tech.com/dell-force10-s4820t-10gbe-switch-os...
    • Broadcom’un bu tür switch ASIC’leriyle çalışmıştım; 40Gb sınıfı değil, 4x10Gbps + 24x1Gbps + CPU için PCIe civarındaydı.
      ASIC fiyatı tahmin edilebilir düzeydeydi; gerçek rakamı bilmiyorum ama birkaç yüz dolar civarı olmalıydı.
      Yazılım arayüzü belgeleri çok yetersizdi; tüm Broadcom switch ASIC’lerini destekleyen bir kütüphane olduğu için yüzlerce MB’lık .a dosyasında “bu cihazda desteklenmiyor” hatası döndüren fonksiyonlarla doluydu ve doğrudan çağırmadan bunu anlamak mümkün değildi.
  • İlginç bir proje.
    Daha basit kullanım için, çoğunlukla yönetilebilir switch çipi kullanan OpenWRT destekli bir router bulunabilir; OpenWRT de VLAN ve birçok seçeneği ayarlamak için iyi bir arayüz sağlar.
    • Günümüzde OpenWRT, Zyxel GS1900 serisi gibi bazı switch’lere de kurulabiliyor.
      Ancak PoE ya da 10Gb/SFP+ port gibi özelliklerin desteği sınırlı olabilir; mevcut durumdan emin değilim.
  • RTL83 serisi switch’lerin yaratıcı şekilde kullanıldığını ilk kez https://spritesmods.com/?art=rtl8366sb adresinde görmüştüm; sonrasında da benzer örnekler oldu.
    Ancak bu proje, “yönetilemeyen bir switch’e dışarıdan beyin takma” yaklaşımından çok, ilk kez gördüğüm doğrudan yapılan yönetilebilir switche daha yakın.
    • Evet, efsanevi sprite_tm; switch’i USB üzerinden yönetmek için Raspberry Pi firmware’i yazarken o yazıyı görmüştüm.
  • Bir Linux makineye birden fazla gigabit adaptör takıp hepsini bir bridge’e koyma yöntemine kıyasla ne avantajı olduğunu merak ediyorum.
    Donanım tarafında performans daha iyi olur gibi, ama gerçek farkı gösteren bir test var mı bilmiyorum.
    • Fark kabaca iş hacmi, gecikme, güç tüketimi ve özelliklerin birleşimi olacaktır.
      USB adaptör kullanırsanız USB birçok açıdan paylaşımlı bir veri yolu olduğu için maksimum bant genişliğine hızla ulaşırsınız; verinin CPU’ya kadar girip sonra tekrar çıkması bunu daha da artırır.
      Yazılımla switch’leme yapıldığında her paketi işleyip doğru yere yeniden göndermek için ek süre gerekir; arayüzlerin kendi gecikmesi de buna eklenir.
      Her adaptörün kendi ağ PHY’si ve donanımı olduğundan güç tüketimi artar; ek işlemeyle birlikte toplam güç kullanımı daha da yükselir.
      Donanım offloading veya diğer performans iyileştirmelerinden de daha az yararlanılır; böylece tüm sistem paket taşımaya daha fazla dahil olur.
      Özellikler açısından seçilen donanıma bağlıdır; ucuz USB gigabit adaptörlerin bazıları VLAN gibi özellikleri düzgün desteklemiyordu.
      Buna karşılık birden fazla PCIe kart kullanılırsa özellikler çok daha iyi hale gelebilir, fakat o noktadan itibaren iş switch’lemeden çok routing’e yaklaşır.
    • Trafiğin çoğu switch’leniyorsa bu yöntem daha verimlidir; çoğunlukla routing gerekiyorsa birden fazla ayrı adaptör daha verimlidir.
    • Diğer yanıtlarda söylendiği gibi bu yöntemin güç tüketiminin daha düşük olma ihtimali yüksek; switch üzerinden geçen gecikme de yazılım bridge’ine göre daha düşük olacaktır.
      Host OS çökse bile switch’leme çalışmaya devam edebilir; watchdog ve kurtarma ile birleştirilirse, kısa süreliğine bazı işlevler çalışmasa bile yazılım bridge’ine göre daha yüksek erişilebilirliğe sahip bir sistem kurulabilir.
      Tabii bunun için switch çipinin kendisinin ölmediği ya da kilitlenmediği varsayımı gerekir.
      Hedefe bağlı olarak, switch’ten geçen tüm trafiği incelemek istiyorsanız 4 arayüz kesinlikle daha iyidir.
      Host tabanlı switch aynı zamanda çok iletişim kuruyorsa 4 arayüz host’a 4Gbps sağlar ve tek bir 1Gbps’e göre avantajlıdır.
      Kurumsal ikinci el quad 1G kartlar eBay’de $15’ın altında alınabilir; ben Silicom quad bypass 1g PEG4BPI-SD modelini tercih ediyorum.
      Bypass özelliği eğlenceli ve sıra dışı olduğu için daha ucuz, ama genelde bir kez “standart NIC” gibi ayarladığınızda büyük sorun yaşamadan başka yerlere takıp kullanabilirsiniz.
      İlk ürünlerde PCI ID’nin tedarikçisi ve alt tedarikçisi Silicom olarak göründüğü için kullanımı daha zordur; -SD kartlarda ise Intel tedarikçi ID’si ve Silicom alt tedarikçisi bulunur, bu yüzden genel sürücü bağlanır.
      4x10G portlarda yönetilecek daha fazla şey vardır ve host sistemine bağlı olarak yazılım bridge’inin iş hacmi yeterli olmayabilir.
      Dört portlu 10G kart bulmak zordur; ama 2x10G, beklerseniz makul fiyata bulunabilir.
    • O yöntemde CPU veri yolunun içine girer.
      Switch, paket switch’lemeyi CPU’da değil ASIC’te yaptığı için sonuç CPU performansına bağlı hale gelir ve genellikle eldeki işlem kaynaklarını verimli kullanmanın bir yolu değildir.
    • Bu kadar düşük hız ve az port sayısı için donanım switch devresi şart değildir.
      Yine de tasarım ve üretim emeğini yok sayarsak toplam donanım maliyeti $100’ın altında olabilir ve birden fazla arayüze sahip bir bilgisayardan daha ucuza gelebilir.
      Ancak 1Gb/s ağ artık oldukça eski sayılır.

Hazır bileşenlerle bile 200 doların biraz üzerinde bir maliyetle daha büyük ve daha hızlı yönetilebilir bir ağ anahtarı yapılabilir
Örneğin 2 portlu bir Odroid H4+ ve 4 Ethernet portu ekleyen bir M.2 genişleme kartı kullanarak 6 portlu 2.5Gb/s bir switch yapılabilir
Bir başka yöntem de N100 CPU’lu ve 4 adet 2.5Gb/s porta sahip küçük bir bilgisayar kullanmak; bu fiyat aralığında çeşitli Çinli üreticilerden satın alınabiliyor
6 adet 2.5Gb/s porta sahip benzer küçük bilgisayarlar biraz daha pahalı olup 300 doların biraz üzerine çıkabiliyor

  • OpenFlow’a ne olduğunu merak ediyorum
    Bu tür cihazlara tam uyacak gibi görünüyor, ama laboratuvar ortamı kurmak neredeyse imkânsız olduğu için ilgimi kaybettim
    • Bu switch çipini veri düzlemi olarak kullanan bir OpenFlow istemcisi yapılabilir; ancak OpenFlow’da kullanılmak istenen işlevlerin çoğu, nispeten sınırlı donanımsal hızlı yolu kullanamayacağı için en iyi seçenek olmayabilir
    • OpenFlow, soruna biraz yanlış bir çözümdü; daha uygun çözüm switchdev veya SAI tarafında
    • Bildiğim kadarıyla OpenFlow fazla genel amaçlı tasarlanmaya çalışıldığı için gerçek donanıma iyi eşlenmedi ve sonunda soyutlamanın sızdığı çok fazla nokta oluştu
  • Okuduğum kadarıyla 10Gbps switch yaparken hızlandırıcı çip üreticileri açık sürücüleri desteklemediğinden, bazı binary blob’lara bağımlı kalmamak çok zor
    CPU ile switching yapmak ağır bir yük getirdiği için böyle çiplere ihtiyaç olduğunu düşünüyorum
    • Marvell 88E6393X, firmware olmadan “basit/harici yönetim” modunda çalışır
      Bu yazıdaki cihaz gibi Linux switchdev ile birlikte kullanılabilir
  • rSTP destekleyip desteklemediğini merak ediyorum
    • Desteklemiyor gibi görünüyor; yalnızca normal STP ve muhtemelen MSTP var gibi
  • Kötü niyetim yok, bir şeyi yanlış anlamış da olabilirim
    Donanım switch’in sistemin geri kalanına nasıl bağlandığını göstermek için RouterBoard blok diyagramını model olarak kullanmışsınız; ardından da bu tür cihazların yönetilemez ya da zor olduğunu savunuyor gibisiniz
    Burada RouterBoard’u gerçekten temin etmeyi denediniz mi merak ediyorum
    Çoğu RouterBoard için OpenWRT derlenebilir olmalı ve 2011 ikinci el piyasasında da oldukça yaygın bir cihazdır
    Daha iyi soru, hedefin en baştan sıfırdan kendin yapmak mı olduğu, yoksa başkasının donanımını kullanma fikrinin belirli bir nedenle mi terk edildiğidir
    • Bu cihazlardan birkaç tane var; asıl amaçları için harikalar, ama özel yazılım çalıştırmak için pek iyi değiller
      RB2011 diyagramını basit ve iyi açıklanmış olduğunu düşündüğüm için kullandım
      Teknik olarak aynı switch çipini kullanan RB1100AHx4 daha iyi bir örnek olurdu; ancak iki CPU portunu birlikte kullanıp kodlama overhead’ini yok sayarak 2 adet 1.25Gbps bağlantıyı 2.5Gbps bağlantı diye sunduğu için daha kafa karıştırıcı
      Sıfırdan yapma nedenim maliyetin makul olması ve bu cihazın FOSDEM video kayıt kutusuna sığması gerekmesi
      O tasarıma özgü bazı sorunları çözmek gerekiyor: kasanın ön panelinde 4 ağ portu dışarı verilirken içerideki SBC’ye de bağlanmaları gerekiyor
      Kasanın içinde, SBC için harici loop kablosu olmadan switch’e kadar passthrough koyacak pek yer yok; basit bir switch kullanılırsa sistem izleme de yapılamıyor
      Bu kutulardan epey fazla yaptığımız için makul bir çözüm oluyor; tasarım süresini saymazsak gönüllü iş olduğu için mümkün
    • RouterBoard RB2011 eski OpenWrt 19.07 sürümüne takılı kalmış durumda: https://openwrt.org/toh/mikrotik/rb2011
      Sorun bir ölçüde NAND ile ilgili görünüyor ve hatırladığım kadarıyla desteklenen diğer RouterBoard’lardan bir şekilde farklı
      Birisi bu sorun için yeni bir çözüm önerdi ama henüz dahil edilmedi: https://forum.openwrt.org/t/wiki-cleanup-for-mikrotik-rb2011... ve diğer başlıklar