1 पॉइंट द्वारा GN⁺ 2024-07-05 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • consumer router के अंदर जैसी संरचना को दोहराने के लिए, जहां स्विच चिप को Linux सीधे नियंत्रित करता है, RTL8367S-आधारित gigabit switch PCB डिज़ाइन किया गया और उसे DSA/switchdev से जोड़ा गया
  • चुना गया RTL8367S 5 ports में built-in PHY वाला 7-port gigabit switch chip है, और dedicated CPU port के बजाय port 0 को network cable से Linux board के Ethernet से जोड़ा गया
  • hardware बनाने की प्रक्रिया में power rails को 3.3V और 1.1V तक सरल किया गया, और boot configuration pins, EEPROM, SPI flash, serial port जैसे configuration paths पर प्रयोग किए गए
  • Linux कनेक्शन के लिए PINE64 A64-lts board, custom kernel options, और Device Tree में बदलाव की जरूरत पड़ी; boot के बाद eth0 के नीचे lan1~lan4 local network interfaces की तरह दिखते हैं
  • यह तरीका Linux bridge और ethtool जैसे मौजूदा tools के साथ अच्छी तरह फिट बैठता है, लेकिन आम PC/server या USB network interfaces पर Device Tree और GPIO constraints की वजह से सीधे इस्तेमाल करना मुश्किल है

Managed switch और Linux DSA architecture

  • सामान्य managed switch में web interface से settings बदली जाती हैं और port status देखा जाता है; अधिक महंगे devices telnet या serial console जैसे अतिरिक्त interfaces भी देते हैं
  • consumer router के अंदर का switch भी अलग श्रेणी का managed switch माना जा सकता है
    • router एक छोटा Linux device होता है और उसके अंदर switch chip होती है
    • एक या अधिक ports CPU से internally connected होते हैं, और बाकी physical ports के रूप में बाहर expose होते हैं
  • Linux के DSA और switchdev subsystems का उपयोग करने पर switch से जुड़े ports वास्तविक “local” network ports की तरह काम करते हैं
  • router SoC और switch के बीच SGMII या RGMII जैसे connection और SMI या MDIO जैसी management bus की जरूरत होती है
  • सामान्य off-the-shelf switches में जरूरी chip connections बाहर expose नहीं होते, इसलिए इस तरीके से उन्हें नियंत्रित करना मुश्किल है

RTL8367S-आधारित switch board बनाना

  • खुद बनाए गए gigabit switch में Realtek RTL8367S chip का उपयोग किया गया
    • यह व्यापक रूप से इस्तेमाल होने वाली 5-port gigabit switch chip है
    • असल में यह 7-port architecture है; 5 ports में PHY built-in है और 2 ports CPU connection के लिए हैं
  • datasheet में केवल न्यूनतम जानकारी थी, इसलिए समान Realtek chips इस्तेमाल करने वाले devices के schematics और Ethernet design documents को साथ में reference किया गया
  • शुरुआत में लगभग 7 power nets की जरूरत लग रही थी, लेकिन overlapping voltage ranges वाले nets को मिलाकर केवल 3.3V और 1.1V regulators वाला configuration संभव हुआ
  • Linux switchdev में CPU connection का dedicated CPU port होना जरूरी नहीं है, इसलिए इस design में port 0 को cable से Linux board से जोड़ा गया
    • switchdev driver के नजरिए से बीच में Ethernet PHY न होने जैसा दिखता है

Switch chip configuration और PCB trial-and-error

  • RTL8367S में कई configuration paths हैं, लेकिन केवल datasheet से सामान्य dumb switch की तरह चलाने के लिए न्यूनतम settings समझना मुश्किल था
    • startup पर पढ़े जाने वाले 8 pins port LED pins के साथ shared हैं
    • i2c bus को EEPROM chip connection के लिए इस्तेमाल किया जा सकता है, लेकिन यह जरूरी SMI bus के साथ pins share करती है
    • SPI bus में NOR flash जोड़कर configuration registers या built-in 8051 core firmware store किया जा सकता है
    • serial port के बारे में माना गया कि 8051 firmware के बिना यह काम नहीं करेगा
  • पहले board के लिए approach यह थी कि उसे खुद order किया जाए और soldering connections बदलते हुए working conditions खोजी जाएं
    • flash chip footprint जोड़ा गया था, लेकिन आखिर में उसकी जरूरत नहीं पड़ी
    • configuration pins पर solder jumpers लगाए गए
    • LED को configurable बनाना मुश्किल था, इसलिए हटा दिया गया
  • gigabit Ethernet design documents impedance control और सटीक length matching पर जोर देते हैं, लेकिन low-cost switches के वास्तविक designs इतने सख्त नहीं लगे
  • अधिक महत्वपूर्ण हिस्सा network pairs के बीच skew matching माना गया
    • सभी 4 network pairs की total length को आपस में match करना उपयोगी नहीं लगा
    • network cable के अंदर भी 4 pairs की twist ratio अलग होती है, इसलिए उनकी length पहले से ही काफी अलग होती है
  • शुरुआती board revision में switch-side transformer center tap को ground से reference करने वाले capacitor treatment में गलती के कारण Ethernet काम नहीं कर रहा था
    • testing में एक छोटी trace काटकर ground short हटाया गया
    • test configuration में center tap floating होने पर भी काम किया
    • final design में संबंधित capacitor जोड़ा गया

तैयार switch और Linux connection

  • तैयार board थोड़ा असामान्य आकार का gigabit switch है
    • 4 ports एक दिशा की ओर हैं
    • 1 port दूसरी दिशा की ओर है और Linux board connection के लिए इस्तेमाल होता है
    • power 2.54mm pin header से supplied होती है
    • USB Type-C connector footprint भी जोड़ा गया ताकि DuPont wire के बिना power दी जा सके
  • testing के लिए Linux board के रूप में PINE64 A64-lts चुना गया
    • connector positions वांछित layout से लगभग मेल खाती थीं
    • Device Tree बदलाव जरूरी था, इसलिए x86 नहीं बल्कि कोई दूसरा platform महत्वपूर्ण था
  • kernel को फिर से build किया गया क्योंकि switch-related modules आमतौर पर enabled नहीं होते
    • CONFIG_NET_DSA: Distributed Switch Architecture
    • CONFIG_NET_DSA_TAG_RTL8_4: Realtek switch chip port tagging
    • CONFIG_NET_SWITCHDEV: network switch driver system
    • CONFIG_NET_DSA_REALTEK, CONFIG_NET_DSA_REALTEK_SMI, CONFIG_NET_DSA_REALTEK_RTL8365MB: actual switch chip driver
  • Device Tree overlay को U-Boot से load करने के बजाय, A64-lts board के Device Tree को सीधे patch किया गया
    • realtek,rtl8365rb compatible string से driver load किया गया
    • यह driver इस्तेमाल किए गए RTL8367S समेत कई Realtek switch chips को support करता है
    • documentation example में CPU port definition को हटाकर 5 सामान्य switch ports define किए गए
  • port@0 पीछे की ओर वाला port है और A64-lts के &emac से जुड़ा है
    • बाकी ports switch chip के अंदर के प्रत्येक PHY से जुड़े हैं
    • Device Tree के top पर SDA/SCL और Reset से जुड़ी 3 GPIOs define की गई हैं

Linux networking tools और constraints

  • boot के बाद Linux में सामान्य eth0 device के साथ Device Tree में define किए गए switch port interfaces दिखाई देते हैं
    • lan1@eth0
    • lan2@eth0
    • lan3@eth0
    • lan4@eth0
  • वास्तव में चलाने के लिए ip link set eth0 up और प्रत्येक lan interface को up करना पड़ता है
  • standard Linux networking tools के साथ integration स्वाभाविक है
    • कई lan ports को Linux bridge में डालने पर switchdev उन ports की bridging को switch chip के अंदर handle करता है
    • Linux को वह traffic खुद forward करने की जरूरत नहीं होती
    • ethtool lan3 से link information देखी जा सकती है
    • ethtool -S lan3 switch द्वारा पूरी तरह process किए गए packets सहित standard status information लौटाता है
  • हालांकि सामान्य environment में इस्तेमाल के लिए constraints काफी बड़े हैं
    • सीधे network switch बनाना होगा या मौजूदा switch खोलकर जरूरी connections ढूंढने होंगे
    • आम PC या server Device Tree-based configuration नहीं होते, और kernel द्वारा controlled GPIO pins भी आमतौर पर उपलब्ध नहीं होते
    • USB network interface में conduit port के रूप में designate करने के लिए Device Tree node handle नहीं होता, इसलिए इस तरीके में उसे इस्तेमाल करना मुश्किल है
  • कुछ constraints को शायद bypass किया जा सके, लेकिन GPIO expose करने वाले special USB devices या ARM device न होने वाले environment में switchdev load करने के तरीके पर और documentation की जरूरत है

1 टिप्पणियां

 
GN⁺ 2024-07-05
Hacker News टिप्पणियां
  • इसे इस तरह भी देखा जा सकता है कि “नेटवर्क स्विच तो एक साधारण डिवाइस है, पैकेट बस अंदर आते हैं और बाहर जाते हैं; सौभाग्य से लोगों ने इसे जटिल बनाने का तरीका ढूंढ लिया और managed switch का आविष्कार कर दिया”, लेकिन महंगे स्विचों में काफी sophisticated ASIC लगे होते हैं
    उदाहरण के लिए, पुराने Dell OS9 स्विचों की एक जोड़ी पुराने stackable उपकरण हैं जिनमें 48 10Gb/s पोर्ट और 4 40Gb/s QSFP+ optical पोर्ट हैं, और एक स्विच अधिकतम 1.28Tb/s संभाल सकता है
    आजकल इन्हें VAT सहित लगभग £1800 में पाया जा सकता है और ये लगभग हमेशा तक चल सकते हैं
    ऐसे प्रयोग अच्छे हैं, लेकिन यह भी ध्यान में रखना चाहिए कि Netgear जैसी कंपनियां सभी पोर्ट पर PoE वाला 8-port 1Gb स्विच करीब £125 में बेचती हैं
    प्रोजेक्ट की economics देखते समय अगर अपने समय को £20~50 प्रति घंटे के हिसाब से गिनें तो off-the-shelf सामान सही हो सकता है, लेकिन अगर लक्ष्य खुद प्रोजेक्ट है तो कीमत की चिंता करने की जरूरत नहीं
    (1) https://i.dell.com/sites/doccontent/shared-content/data-shee...
    (2) https://www.etb-tech.com/dell-force10-s4820t-10gbe-switch-os...
    • मैंने Broadcom के ऐसे switch ASIC के साथ काम किया है; वह 40Gb-क्लास का नहीं था, बल्कि लगभग 4x10Gbps + 24x1Gbps + CPU के लिए PCIe वाला था
      ASIC की कीमत अंदाजा लगाने लायक स्तर पर थी; असली आंकड़ा नहीं पता, लेकिन शायद कुछ सौ डॉलर रही होगी
      software interface documentation बहुत खराब थी, और क्योंकि library सभी Broadcom switch ASIC को support करती थी, उसमें सैकड़ों MB की .a file में ऐसे functions भरे थे जो बस “इस device पर support नहीं है” error लौटाते थे; जब तक खुद call करके न देखें, पता नहीं चलता था
  • दिलचस्प प्रोजेक्ट है
    ज्यादा सरल उपयोग के लिए, OpenWRT-supported routers मिल जाते हैं जो ज्यादातर managed switch chips इस्तेमाल करते हैं, और OpenWRT VLAN तथा कई options set करने के लिए अच्छा interface देता है
    • आजकल OpenWRT को Zyxel GS1900 series जैसे कुछ switches पर भी install किया जा सकता है
      हालांकि PoE या 10Gb/SFP+ ports जैसी features का support सीमित हो सकता है, और मौजूदा स्थिति पक्की नहीं है
  • RTL83 series switch को creatively इस्तेमाल करते हुए मैंने पहली बार https://spritesmods.com/?art=rtl8366sb में देखा था, और बाद में भी ऐसे मिलते-जुलते उदाहरण रहे
    लेकिन यह प्रोजेक्ट “unmanaged switch में बाहरी दिमाग जोड़ने” वाला तरीका नहीं, बल्कि पहली बार देखा हुआ खुद बनाया managed switch जैसा है
    • हां, वही legendary sprite_tm; USB से switch manage करने वाला Raspberry Pi firmware खुद लिखते समय मैंने वह लेख देखा था
  • मुझे उत्सुकता है कि Linux machine में कई gigabit adapters लगाकर सभी को bridge में डालने की तुलना में इसका क्या फायदा है
    hardware-side performance बेहतर होगी, ऐसा लगता तो है, लेकिन कोई test था या नहीं जो असली फर्क दिखाता हो, पता नहीं
    • फर्क मोटे तौर पर throughput, latency, power usage और features के combination में होगा
      USB adapters इस्तेमाल करने पर USB कई मायनों में shared bus है, इसलिए maximum bandwidth से जल्दी टकराते हैं; ऊपर से data को CPU तक आकर फिर वापस बाहर जाना पड़ता है
      software से switching करने पर हर packet को process करके सही जगह फिर भेजने का extra time लगता है, और interface की अपनी latency भी जुड़ती है
      हर adapter में अपना network PHY और hardware होता है, जिससे power consumption बढ़ता है, और अतिरिक्त processing मिलाकर power usage और बढ़ जाती है
      hardware offloading या अन्य performance improvements का उपयोग भी कम हो पाता है, इसलिए पूरा system packet movement में ज्यादा शामिल हो जाता है
      features के मामले में यह चुने गए hardware पर निर्भर करता है; सस्ते USB gigabit adapters में से कुछ में VLAN जैसे features ठीक से काम नहीं करते थे
      उल्टा, अगर कई PCIe cards इस्तेमाल करें तो features काफी बेहतर हो सकते हैं, लेकिन उस point से यह switching की बजाय routing के ज्यादा करीब हो जाता है
    • अगर ज्यादातर traffic switching है, तो यह तरीका ज्यादा efficient है; अगर ज्यादातर routing चाहिए, तो कई अलग adapters ज्यादा efficient हैं
    • दूसरे जवाबों की तरह, इस तरीके में power usage कम होने की संभावना ज्यादा है, और software bridge की तुलना में switch से गुजरने वाली latency भी कम होगी
      host OS मर भी जाए तो switching चलती रह सकती है, और watchdog व recovery को जोड़ दें तो कुछ features थोड़ी देर न चलें तब भी software bridge की तुलना में बेहतर availability वाला system बनाया जा सकता है
      बस यह मानना होगा कि switch chip खुद dead या hang नहीं होता
      लक्ष्य पर निर्भर करता है, लेकिन switch से गुजरने वाले सारे traffic को inspect करना हो तो 4 interfaces निश्चित रूप से बेहतर हैं
      अगर host-based switch खुद भी काफी communication करता है, तो 4 interfaces host को 4Gbps देते हैं और single 1Gbps से बेहतर हैं
      enterprise second-hand quad 1G cards eBay पर $15 से कम में खरीदे जा सकते हैं, और मुझे Silicom quad bypass 1g PEG4BPI-SD पसंद है
      bypass feature मजेदार और असामान्य है इसलिए यह और सस्ता है, लेकिन आम तौर पर एक बार “standard NIC” की तरह set कर दें तो बड़ी समस्या के बिना दूसरी जगह लगाकर इस्तेमाल किया जा सकता है
      शुरुआती products में PCI ID का vendor और sub-vendor Silicom के रूप में दिखता है, इसलिए इस्तेमाल करना ज्यादा कठिन है; -SD card में Intel vendor ID और Silicom sub-vendor है, इसलिए generic driver attach हो जाता है
      4x10G ports में manage करने के लिए ज्यादा चीजें होती हैं, और host system के हिसाब से software bridging throughput पर्याप्त नहीं हो सकता
      quad-port 10G cards मिलना मुश्किल है, लेकिन 2x10G इंतजार करें तो reasonable price पर मिल सकता है
    • उस तरीके में CPU data path में आ जाता है
      switch CPU नहीं, ASIC में packet switching करता है, इसलिए यह CPU performance पर निर्भर करता है, और आम तौर पर उपलब्ध compute resources का efficient use नहीं है
    • इतनी कम speed और इतने कम ports के लिए hardware switch circuitry जरूरी नहीं है
      फिर भी design और manufacturing effort को नजरअंदाज करें तो कुल hardware cost $100 से कम हो सकती है, और कई interfaces वाले computer से सस्ता पड़ने की संभावना है
      हालांकि 1Gb/s network काफी पुराना माना जाएगा

तैयार पार्ट्स से ही $200 से थोड़ा ज़्यादा खर्च में बड़ा और तेज़ managed network switch बनाया जा सकता है
उदाहरण के लिए, 2 पोर्ट वाले Odroid H4+ और 4 अतिरिक्त Ethernet पोर्ट जोड़ने वाले M.2 expansion card का उपयोग करके 6-पोर्ट 2.5Gb/s switch बनाया जा सकता है
एक और तरीका N100 CPU और 4 2.5Gb/s पोर्ट वाले छोटे computer का इस्तेमाल करना है, जिसे कई चीनी कंपनियों से इसी price range में खरीदा जा सकता है
6 2.5Gb/s पोर्ट वाले मिलते-जुलते छोटे computer थोड़े महंगे हैं और $300 से थोड़ा ऊपर जा सकते हैं

  • सोच रहा हूँ OpenFlow का क्या हुआ
    यह ऐसे device के लिए बिल्कुल फिट लगता है, लेकिन lab environment तैयार करना लगभग असंभव था, इसलिए मेरी रुचि खत्म हो गई
    • इस switch chip को data plane की तरह इस्तेमाल करने वाला OpenFlow client बनाया जा सकता है, लेकिन OpenFlow में उपयोग की जाने वाली अधिकांश सुविधाएँ शायद अपेक्षाकृत सीमित hardware fast path का फायदा नहीं उठा पाएँगी, इसलिए यह सबसे अच्छा विकल्प नहीं हो सकता
    • OpenFlow समस्या का थोड़ा गलत समाधान था; ज़्यादा सही समाधान switchdev या SAI की तरफ है
    • मेरी जानकारी में OpenFlow को बहुत ज़्यादा general-purpose बनाने की कोशिश की गई, इसलिए वह वास्तविक hardware पर अच्छी तरह map नहीं हुआ और अंत में abstraction में कई leak रह गए
  • जितना मैंने पढ़ा है, 10Gbps switch बनाते समय accelerator chip बनाने वाली कंपनियाँ open drivers support नहीं करतीं, इसलिए कुछ binary blobs पर निर्भर न रहना बहुत मुश्किल है
    CPU से switching करने पर load बहुत ज़्यादा होता है, इसलिए ऐसे chip की ज़रूरत पड़ती है
    • Marvell 88E6393X बिना firmware के “simple/external management” mode में चलता है
      इसे इस लेख के device की तरह Linux switchdev के साथ इस्तेमाल किया जा सकता है
  • जानना चाहता हूँ कि क्या यह rSTP support करता है
    • लगता है support नहीं करता; शायद सिर्फ सामान्य STP और MSTP ही करता है
  • कोई बुरी नीयत नहीं है, और हो सकता है मैंने कुछ गलत समझा हो
    आपने hardware switch system के बाकी हिस्से से कैसे जुड़ता है यह दिखाने के लिए RouterBoard block diagram को model की तरह इस्तेमाल किया, लेकिन फिर ऐसा लगता है कि आप कह रहे हैं कि ऐसे devices को handle करना असंभव या मुश्किल है
    यहाँ मुझे उत्सुकता है कि क्या आपने सच में RouterBoard हासिल करके देखा है
    ज़्यादातर RouterBoard के लिए OpenWRT build किया जा सकता होगा, और 2011 second-hand market में भी काफी आम device होगा
    बेहतर सवाल यह है कि लक्ष्य शुरू से ही scratch से खुद बनाना था, या किसी खास वजह से दूसरों का hardware इस्तेमाल करने का विचार छोड़ दिया गया था
    • मेरे पास ऐसे कई device हैं, और वे अपने मूल उद्देश्य के लिए बेहतरीन हैं, लेकिन custom software चलाने के लिए इतने अच्छे नहीं हैं
      RB2011 diagram इसलिए लिया क्योंकि मुझे लगा यह simple है और अच्छी तरह समझाया गया है
      तकनीकी रूप से वही switch chip इस्तेमाल करने वाला RB1100AHx4 बेहतर उदाहरण है, लेकिन वह दोनों CPU ports को साथ इस्तेमाल करता है और encoding overhead को नज़रअंदाज़ करके 2 × 1.25Gbps links को 2.5Gbps link बताता है, जिससे बात और उलझ जाती है
      scratch से बनाने की वजह यह है कि cost reasonable है, और इस device को FOSDEM video recording box में फिट होना है
      उस design से जुड़ी कुछ खास समस्याएँ हल करनी हैं: case के front panel पर 4 network ports expose करने हैं और उन्हें अंदर के SBC से भी connect होना है
      case के अंदर SBC के लिए external loop cable के बिना switch तक passthrough डालने की बहुत जगह नहीं है, और साधारण switch इस्तेमाल करने पर system monitoring भी नहीं हो पाएगी
      हम ऐसे कई boxes बनाते हैं, इसलिए यह reasonable समाधान बन जाता है; design time को नज़रअंदाज़ करें तो यह volunteer work है, इसलिए संभव है
    • RouterBoard RB2011 पुराने OpenWrt 19.07 release पर अटका हुआ है: https://openwrt.org/toh/mikrotik/rb2011
      समस्या NAND से कुछ हद तक जुड़ी लगती है, और जहाँ तक याद है, supported दूसरे RouterBoards से कुछ अलग है
      किसी ने इस issue के लिए नया समाधान propose किया था, लेकिन वह अभी merge नहीं हुआ है: https://forum.openwrt.org/t/wiki-cleanup-for-mikrotik-rb2011... और अन्य threads