การสร้างสวิตช์เครือข่ายที่จัดการโดย Linux
(blog.brixit.nl)- ออกแบบ PCB สวิตช์กิกะบิตที่ใช้ RTL8367S และเชื่อมต่อเข้ากับ DSA/switchdev เพื่อจำลองโครงสร้างที่ Linux ควบคุมชิปสวิตช์โดยตรง เหมือนภายในเราเตอร์สำหรับผู้บริโภค
- RTL8367S ที่เลือกใช้เป็นชิปสวิตช์กิกะบิต 7 พอร์ต โดยมี PHY ในตัว 5 พอร์ต และแทนที่จะใช้พอร์ต CPU เฉพาะ ก็เชื่อมต่อพอร์ต 0 เข้ากับอีเทอร์เน็ตของบอร์ด Linux ด้วยสายเครือข่าย
- ในกระบวนการสร้างฮาร์ดแวร์ ได้ทำให้รางไฟเรียบง่ายเหลือ 3.3V และ 1.1V และทดลองเส้นทางการตั้งค่าต่าง ๆ เช่น ขาตั้งค่าตอนบูต, EEPROM, SPI flash และพอร์ต serial
- การเชื่อมต่อกับ Linux ต้องใช้บอร์ด PINE64 A64-lts, ตัวเลือกเคอร์เนลแบบกำหนดเอง และการแก้ไข Device Tree หลังบูต
lan1~lan4จะปรากฏใต้eth0เหมือนอินเทอร์เฟซเครือข่ายท้องถิ่น - วิธีนี้เข้ากันได้ดีกับเครื่องมือเดิมอย่าง Linux bridge และ
ethtoolแต่ใช้กับ PC/เซิร์ฟเวอร์ทั่วไปหรืออินเทอร์เฟซเครือข่าย USB ได้ยากทันที เนื่องจาก ข้อจำกัดของ Device Tree และ GPIO
สวิตช์แบบจัดการได้และโครงสร้าง Linux DSA
- สวิตช์แบบจัดการได้ทั่วไปจะเปลี่ยนการตั้งค่าและตรวจสอบสถานะพอร์ตผ่านเว็บอินเทอร์เฟซ ส่วนอุปกรณ์ที่แพงกว่าจะมีอินเทอร์เฟซเพิ่มเติม เช่น telnet หรือ serial console
- สวิตช์ภายในเราเตอร์สำหรับผู้บริโภคก็ถือเป็น สวิตช์แบบจัดการได้ อีกประเภทหนึ่งได้
- เราเตอร์เป็นอุปกรณ์ Linux ขนาดเล็ก และมีชิปสวิตช์อยู่ภายใน
- พอร์ตอย่างน้อยหนึ่งพอร์ตเชื่อมต่อภายในกับ CPU ส่วนที่เหลือถูกนำออกมาเป็นพอร์ตจริงภายนอก
- เมื่อใช้ซับซิสเต็ม DSA และ switchdev ของ Linux พอร์ตที่เชื่อมต่อกับสวิตช์จะทำงานเหมือนพอร์ตเครือข่าย “local” จริง
- ระหว่าง router SoC กับสวิตช์ต้องมีการเชื่อมต่ออย่าง SGMII หรือ RGMII และบัสจัดการอย่าง SMI หรือ MDIO
- สวิตช์สำเร็จรูปทั่วไปควบคุมด้วยวิธีนี้ได้ยาก เพราะการเชื่อมต่อชิปที่จำเป็นไม่ได้ถูกนำออกมาภายนอก
การสร้างบอร์ดสวิตช์บน RTL8367S
- สวิตช์กิกะบิตที่สร้างเองใช้ชิป Realtek RTL8367S
- เป็นชิปสวิตช์กิกะบิต 5 พอร์ตที่ใช้กันแพร่หลาย
- จริง ๆ แล้วมีโครงสร้าง 7 พอร์ต โดย 5 พอร์ตมี PHY ในตัว และอีก 2 พอร์ตใช้สำหรับเชื่อมต่อ CPU
- datasheet ให้ข้อมูลเพียงขั้นต่ำ จึงอ้างอิง schematic ของอุปกรณ์ที่ใช้ชิป Realtek คล้ายกันและเอกสารออกแบบอีเทอร์เน็ตประกอบกัน
- ตอนแรกดูเหมือนต้องใช้ net ไฟเลี้ยงประมาณ 7 ชุด แต่สามารถรวม net ที่ช่วงแรงดันทับซ้อนกันได้ ทำให้ใช้เพียงเรกูเลเตอร์ 3.3V และ 1.1V
- Linux switchdev ไม่ได้บังคับว่าการเชื่อมต่อ CPU ต้องเป็นพอร์ต CPU เฉพาะ ดังนั้นในการออกแบบนี้จึงเชื่อมต่อพอร์ต 0 เข้ากับบอร์ด Linux ด้วยสายเคเบิล
- จากมุมมองของไดรเวอร์ switchdev จะดูเหมือนไม่มี Ethernet PHY คั่นอยู่กลางทาง
การตั้งค่าชิปสวิตช์และการลองผิดลองถูกกับ PCB
- RTL8367S มี เส้นทางการตั้งค่า หลายแบบ แต่จาก datasheet อย่างเดียวเข้าใจการตั้งค่าขั้นต่ำเพื่อให้ทำงานเป็น dumb switch ทั่วไปได้ยาก
- ขา 8 ขาที่อ่านตอนเริ่มต้นถูกใช้ร่วมกับขา LED ของพอร์ต
- บัส i2c ใช้ต่อกับชิป EEPROM ได้ แต่ใช้ขาร่วมกับบัส SMI ที่จำเป็น
- บัส SPI สามารถต่อ NOR flash เพื่อเก็บรีจิสเตอร์การตั้งค่าหรือ firmware ของคอร์ 8051 ภายในได้
- ประเมินว่าพอร์ต serial จะไม่ทำงานหากไม่มี firmware ของ 8051
- บอร์ดรุ่นแรกใช้วิธีสั่งทำเอง แล้วค่อยเปลี่ยนการบัดกรีเชื่อมต่อไปเรื่อย ๆ เพื่อหาสภาวะที่ทำงานได้
- ใส่ footprint สำหรับชิป flash ไว้ แต่สุดท้ายไม่จำเป็น
- ใส่ solder jumper ไว้ที่ขาตั้งค่า
- ตัด LED ออก เพราะทำให้ตั้งค่าได้ยาก
- เอกสารออกแบบอีเทอร์เน็ตกิกะบิตเน้นการควบคุม impedance และการจับคู่ความยาวอย่างแม่นยำ แต่การออกแบบของสวิตช์ราคาถูกที่เห็นจริงไม่ได้ดูเข้มงวดขนาดนั้น
- ส่วนที่ให้ความสำคัญมากกว่าคือ การจับคู่ skew ระหว่างคู่สัญญาณเครือข่าย
- มองว่าการทำให้ความยาวรวมของคู่สัญญาณเครือข่ายทั้ง 4 คู่เท่ากันไม่มีประโยชน์นัก
- ภายในสายเครือข่ายเอง คู่สายทั้ง 4 คู่ก็มีอัตราการบิดเกลียวต่างกัน ทำให้ความยาวต่างกันมากอยู่แล้ว
- ใน revision แรกของบอร์ด อีเทอร์เน็ตไม่ทำงาน เพราะจัดการคาปาซิเตอร์ที่อ้างอิง center tap ของทรานส์ฟอร์เมอร์ฝั่งสวิตช์ลงกราวด์ผิด
- ในการทดสอบได้ตัด trace เล็ก ๆ เพื่อตัดการช็อตลงกราวด์
- ในชุดทดสอบ ถึง center tap จะลอยอยู่ก็ยังทำงานได้
- ในแบบสุดท้ายได้เพิ่มคาปาซิเตอร์ดังกล่าวเข้าไป
สวิตช์ที่เสร็จสมบูรณ์และการเชื่อมต่อกับ Linux
- บอร์ดที่เสร็จแล้วเป็น สวิตช์กิกะบิต ที่มีรูปทรงค่อนข้างแปลก
- พอร์ต 4 พอร์ตหันไปทางเดียวกัน
- อีก 1 พอร์ตหันไปทางตรงข้าม และใช้เชื่อมต่อกับบอร์ด Linux
- จ่ายไฟผ่าน pin header ระยะ 2.54mm
- เพิ่ม footprint สำหรับคอนเนกเตอร์ USB Type-C ด้วย เพื่อให้จ่ายไฟได้โดยไม่ต้องใช้สาย DuPont
- เลือกใช้บอร์ด Linux สำหรับทดสอบเป็น PINE64 A64-lts
- ตำแหน่งคอนเนกเตอร์ใกล้เคียงกับ layout ที่ต้องการ
- เนื่องจากต้องแก้ Device Tree แพลตฟอร์มที่ไม่ใช่ x86 จึงสำคัญ
- โดยปกติโมดูลที่เกี่ยวกับสวิตช์ในเคอร์เนลไม่ได้เปิดใช้งาน จึงต้อง build ใหม่
CONFIG_NET_DSA: Distributed Switch ArchitectureCONFIG_NET_DSA_TAG_RTL8_4: การแท็กพอร์ตของชิปสวิตช์ RealtekCONFIG_NET_SWITCHDEV: ระบบไดรเวอร์สวิตช์เครือข่ายCONFIG_NET_DSA_REALTEK,CONFIG_NET_DSA_REALTEK_SMI,CONFIG_NET_DSA_REALTEK_RTL8365MB: ไดรเวอร์ชิปสวิตช์จริง
- แทนที่จะโหลด Device Tree overlay ด้วย U-Boot ได้ patch Device Tree ของบอร์ด A64-lts โดยตรง
- โหลดไดรเวอร์ด้วย compatible string
realtek,rtl8365rb - ไดรเวอร์นี้รองรับชิปสวิตช์ Realtek หลายรุ่น รวมถึง RTL8367S ที่ใช้ด้วย
- ลบการกำหนดพอร์ต CPU จากตัวอย่างในเอกสาร และกำหนดพอร์ตสวิตช์ทั่วไป 5 พอร์ต
- โหลดไดรเวอร์ด้วย compatible string
port@0คือพอร์ตที่หันไปด้านหลัง และเชื่อมต่อกับ&emacของ A64-lts- พอร์ตที่เหลือเชื่อมต่อกับ PHY แต่ละตัวภายในชิปสวิตช์
- ด้านบนของ Device Tree กำหนด GPIO 3 ขาที่เชื่อมกับ SDA/SCL และ Reset
เครื่องมือเครือข่ายของ Linux และข้อจำกัด
- หลังบูต Linux จะเห็นอินเทอร์เฟซพอร์ตสวิตช์ที่กำหนดไว้ใน Device Tree พร้อมกับอุปกรณ์
eth0ทั่วไปlan1@eth0lan2@eth0lan3@eth0lan4@eth0
- หากต้องการให้ทำงานจริง ต้องสั่ง
ip link set eth0 upและเปิดอินเทอร์เฟซlanแต่ละตัวด้วย - การผสานกับเครื่องมือเครือข่ายมาตรฐานของ Linux เป็นไปอย่างเป็นธรรมชาติ
- เมื่อใส่พอร์ต
lanหลายพอร์ตเข้าใน Linux bridge, switchdev จะจัดการ bridging ของพอร์ตเหล่านั้นภายในชิปสวิตช์ - Linux ไม่จำเป็นต้อง forward traffic นั้นเอง
- ดูข้อมูลลิงก์ได้ด้วย
ethtool lan3 ethtool -S lan3จะคืนค่าสถานะมาตรฐาน รวมถึงแพ็กเก็ตที่สวิตช์จัดการทั้งหมดเอง
- เมื่อใส่พอร์ต
- อย่างไรก็ตาม การใช้งานในสภาพแวดล้อมทั่วไปมีข้อจำกัดมาก
- ต้องสร้างสวิตช์เครือข่ายเอง หรือเปิดสวิตช์ที่มีอยู่เพื่อหาการเชื่อมต่อที่จำเป็น
- PC หรือเซิร์ฟเวอร์ทั่วไปไม่ได้ใช้การกำหนดค่าบน Device Tree และโดยปกติก็ไม่มีขา GPIO ที่เคอร์เนลควบคุมได้ให้ใช้
- อินเทอร์เฟซเครือข่าย USB ใช้วิธีนี้ได้ยาก เพราะไม่มี handle ของโหนด Device Tree สำหรับกำหนดเป็นพอร์ต conduit
- ข้อจำกัดบางอย่างอาจมีวิธีเลี่ยงได้ แต่ยังต้องมีเอกสารเพิ่มเติมเกี่ยวกับวิธีโหลด switchdev ในสภาพแวดล้อมที่ไม่ใช่อุปกรณ์ USB พิเศษที่ expose GPIO หรืออุปกรณ์ ARM
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ตัวอย่างเช่น สวิตช์ Dell OS9 รุ่นเก่าคู่หนึ่งเป็นอุปกรณ์แบบสแตกยุคก่อนที่มีพอร์ต 10Gb/s จำนวน 48 พอร์ต และพอร์ตไฟเบอร์ QSFP+ 40Gb/s จำนวน 4 พอร์ต โดยสวิตช์หนึ่งตัวรองรับได้สูงสุด 1.28Tb/s
ทุกวันนี้หาซื้อได้ราว £1800 รวม VAT และแทบจะใช้ได้ไปตลอดกาล
ความพยายามแบบนี้ก็น่าสนใจ แต่ก็ควรคำนึงด้วยว่าเจ้าอย่าง Netgear ขายสวิตช์ 8 พอร์ต 1Gb ที่ทุกพอร์ตรองรับ PoE ในราคาราว £125
ถ้ามองเรื่องความคุ้มค่าทางเศรษฐกิจของโปรเจ็กต์แล้วตีเวลาทำงานเป็นชั่วโมงละ £20~50 ของสำเร็จรูปอาจเหมาะกว่า แต่ถ้าจุดประสงค์คือทำโปรเจ็กต์นั้นเอง ก็ไม่จำเป็นต้องกังวลเรื่องราคา
(1) https://i.dell.com/sites/doccontent/shared-content/data-shee...
(2) https://www.etb-tech.com/dell-force10-s4820t-10gbe-switch-os...
ราคา ASIC ก็อยู่ในระดับที่พอเดาได้ แม้ไม่รู้ตัวเลขจริงแต่คงประมาณหลายร้อยดอลลาร์
เอกสารอินเทอร์เฟซซอฟต์แวร์แย่มาก และเพราะเป็นไลบรารีที่รองรับ switch ASIC ของ Broadcom ทุกตัว จึงได้ไฟล์
.aขนาดหลายร้อย MB ที่เต็มไปด้วยฟังก์ชันซึ่งคืนค่าแค่ว่า “ไม่รองรับบนอุปกรณ์นี้” และจะรู้ได้ก็ต่อเมื่อเรียกใช้เองถ้าใช้งานง่ายกว่านี้ ส่วนใหญ่สามารถหาเราเตอร์ที่รองรับ OpenWRT และใช้ ชิป managed switch ได้ โดย OpenWRT มีอินเทอร์เฟซที่ดีสำหรับตั้งค่า VLAN และตัวเลือกต่าง ๆ
แต่การรองรับฟีเจอร์อย่าง PoE หรือพอร์ต 10Gb/SFP+ อาจยังมีข้อจำกัด และสถานะปัจจุบันก็ยังไม่แน่ชัด
แต่โปรเจ็กต์นี้ดูใกล้เคียงกับ การสร้าง managed switch เอง ที่เพิ่งเคยเห็นเป็นครั้งแรก มากกว่าจะเป็นแนว “เอาสมองภายนอกมาต่อกับ unmanaged switch”
เดาว่าด้านฮาร์ดแวร์คงแรงกว่า แต่ไม่แน่ใจว่าเคยมีการทดสอบที่แสดงความต่างจริงหรือไม่
ถ้าใช้อะแดปเตอร์ USB ก็จะชนเพดานแบนด์วิดท์ได้เร็ว เพราะ USB เป็น shared bus ในหลายแง่มุม และข้อมูลต้องวิ่งเข้า CPU แล้วค่อยออกไปอีกที
ถ้าสวิตช์ด้วยซอฟต์แวร์ ก็มีเวลาเพิ่มขึ้นจากการประมวลผลแต่ละแพ็กเก็ตและส่งกลับออกไปยังปลายทางที่ถูกต้อง รวมถึง latency ของอินเทอร์เฟซเองด้วย
อะแดปเตอร์แต่ละตัวมี network PHY และฮาร์ดแวร์ของตัวเอง จึงกินไฟเพิ่ม และเมื่อรวมกับภาระประมวลผลเพิ่มเติมก็ยิ่งใช้พลังงานมากขึ้น
ยังใช้ประโยชน์จาก hardware offloading หรือการปรับปรุงประสิทธิภาพอื่น ๆ ได้น้อยลง ทำให้ทั้งระบบต้องเข้ามาเกี่ยวข้องกับการเคลื่อนย้ายแพ็กเก็ตมากขึ้น
ในด้านฟีเจอร์ก็ขึ้นกับฮาร์ดแวร์ที่เลือก และอะแดปเตอร์ USB gigabit ราคาถูกบางตัวก็รองรับ VLAN ได้ไม่ดี
ในทางกลับกัน ถ้าใช้การ์ด PCIe หลายใบ ฟีเจอร์อาจดีขึ้นมาก แต่พอถึงจุดนั้นมันก็เริ่มใกล้กับการทำ routing มากกว่าการ switching
ถึง host OS จะล่ม การ switching ก็อาจยังทำงานต่อได้ และถ้ารวม watchdog กับกลไกกู้คืนไว้ แม้บางฟังก์ชันจะใช้ไม่ได้ชั่วคราว ก็ยังสร้างระบบที่ availability ดีกว่าซอฟต์แวร์บริดจ์ได้
แน่นอนว่าต้องตั้งอยู่บนสมมติฐานว่าตัวชิปสวิตช์เองไม่ตายหรือไม่ค้าง
แล้วแต่เป้าหมาย แต่ถ้าต้องการตรวจสอบทราฟฟิกทั้งหมดที่ผ่านสวิตช์ การมี 4 อินเทอร์เฟซย่อมดีกว่าอย่างชัดเจน
ถ้าโฮสต์เบสสวิตช์มีการสื่อสารมากด้วย 4 อินเทอร์เฟซก็จะให้ 4Gbps จากฝั่งโฮสต์ ซึ่งดีกว่า 1Gbps เส้นเดียว
การ์ดมือสองระดับองค์กรแบบ quad 1G หาซื้อบน eBay ได้ต่ำกว่า $15 และผมชอบ Silicom quad bypass 1g
PEG4BPI-SDฟังก์ชัน bypass นั้นแปลกและน่าสนุกจึงยิ่งทำให้มันถูกลง แต่โดยทั่วไปถ้าตั้งค่าเป็น “standard NIC” ไว้ครั้งหนึ่งแล้ว ก็มักจะเอาไปเสียบใช้ที่อื่นต่อได้ไม่มีปัญหาใหญ่
รุ่นแรก ๆ มี vendor และ subvendor ใน PCI ID เป็น Silicom ทำให้ใช้งานยากกว่า ส่วนการ์ด
-SDใช้ vendor ID ของ Intel และ subvendor ของ Silicom จึงใช้ไดรเวอร์ทั่วไปได้พอร์ต 4x10G มีสิ่งให้ดูแลมากขึ้น และขึ้นกับระบบโฮสต์ว่า throughput ของ software bridging จะพอหรือไม่
การ์ด quad port 10G หายาก แต่ถ้ารอจังหวะดี ๆ การ์ด 2x10G ก็หาได้ในราคาสมเหตุสมผล
สวิตช์ใช้ ASIC สวิตช์แพ็กเก็ต ไม่ใช่ CPU ดังนั้นมันจึงขึ้นกับประสิทธิภาพ CPU และโดยทั่วไปไม่ใช่วิธีใช้ทรัพยากรประมวลผลที่มีอยู่อย่างคุ้มค่าที่สุด
ถึงอย่างนั้น ถ้าไม่นับแรงออกแบบและประกอบ ต้นทุนฮาร์ดแวร์รวมอาจต่ำกว่า $100 และอาจถูกกว่าคอมพิวเตอร์ที่มีหลายอินเทอร์เฟซ
เพียงแต่เครือข่าย 1Gb/s ก็ถือว่าค่อนข้างเก่าแล้ว
ยังสามารถสร้างสวิตช์เครือข่ายแบบจัดการได้ที่ใหญ่กว่าและเร็วกว่า ด้วยค่าใช้จ่ายเพียงมากกว่า $200 เล็กน้อย โดยใช้แค่ชิ้นส่วนสำเร็จรูป
ตัวอย่างเช่น ถ้าใช้ Odroid H4+ ที่มี 2 พอร์ต ร่วมกับการ์ดขยาย M.2 ที่เพิ่มพอร์ต Ethernet อีก 4 พอร์ต ก็สามารถสร้างสวิตช์ 2.5Gb/s แบบ 6 พอร์ตได้
อีกวิธีหนึ่งคือใช้คอมพิวเตอร์ขนาดเล็กที่มี CPU N100 และพอร์ต 2.5Gb/s จำนวน 4 พอร์ต ซึ่งมีขายในช่วงราคานี้จากผู้ผลิตจีนหลายราย
คอมพิวเตอร์ขนาดเล็กที่คล้ายกันแต่มี 6 พอร์ต 2.5Gb/s จะแพงกว่าเล็กน้อย และอาจเกิน $300 ไปนิดหน่อย
มันดูเหมือนจะเหมาะกับอุปกรณ์แบบนี้มาก แต่พอแทบจะจัดสภาพแวดล้อมสำหรับทดลองไม่ได้เลยก็เลยหมดความสนใจ
ถ้าสวิตช์ด้วย CPU อย่างเดียวภาระจะหนักมาก จึงคิดว่าจำเป็นต้องมีชิปพวกนั้น
88E6393Xทำงานในโหมด “simple/external management” ได้โดยไม่ต้องมีเฟิร์มแวร์จึงใช้งานร่วมกับ Linux switchdev ได้แบบเดียวกับอุปกรณ์ในบทความนี้
คุณใช้ block diagram ของ RouterBoard เป็นต้นแบบเพื่อแสดงให้เห็นว่าฮาร์ดแวร์สวิตช์เชื่อมต่อกับส่วนอื่นของระบบอย่างไร แต่หลังจากนั้นกลับดูเหมือนจะบอกว่าอุปกรณ์แบบนั้นใช้งานจริงไม่ได้หรือใช้งานยาก
เลยสงสัยว่าที่นี่มีใครเคยหา RouterBoard มาใช้จริงบ้างหรือไม่
น่าจะ build OpenWRT สำหรับ RouterBoard ส่วนใหญ่ได้ และรุ่น 2011 ก็น่าจะเป็นอุปกรณ์ที่พบได้ค่อนข้างบ่อยในตลาดมือสอง
คำถามที่ดีกว่าคือ เป้าหมายตั้งแต่แรกคือ การสร้างขึ้นเองตั้งแต่ศูนย์ หรือว่ามีเหตุผลบางอย่างที่ทำให้ตัดแนวคิดการใช้ฮาร์ดแวร์ของคนอื่นทิ้งไป
ผมหยิบไดอะแกรมของ RB2011 มาใช้เพราะคิดว่ามันเรียบง่ายและอธิบายได้ดี
ในเชิงเทคนิคแล้ว RB1100AHx4 ที่ใช้ชิปสวิตช์ตัวเดียวกันเป็นตัวอย่างที่ดีกว่า แต่ยิ่งทำให้งงกว่าเดิม เพราะมันใช้พอร์ต CPU สองพอร์ตร่วมกัน และอ้างว่าลิงก์ 1.25Gbps จำนวน 2 เส้นเป็นลิงก์ 2.5Gbps โดยไม่สนใจ overhead จากการเข้ารหัส
เหตุผลที่สร้างขึ้นเองตั้งแต่ต้นคือค่าใช้จ่ายสมเหตุสมผล และอุปกรณ์นี้ต้องถูกใส่ไว้ในกล่องบันทึกวิดีโอของ FOSDEM
จำเป็นต้องแก้ปัญหาเฉพาะบางอย่างของการออกแบบนั้น เช่น ต้องเปิดพอร์ตเครือข่าย 4 พอร์ตที่แผงหน้าของเคส และในขณะเดียวกันก็ต้องเชื่อมต่อเข้ากับ SBC ภายในด้วย
ภายในเคสแทบไม่มีพื้นที่พอจะใส่ pass-through ไปยังสวิตช์โดยไม่ต้องใช้สายลูปภายนอกสำหรับ SBC และถ้าใช้สวิตช์ธรรมดาก็จะไม่สามารถทำ system monitoring ได้ด้วย
เนื่องจากเราจะสร้างกล่องแบบนี้หลายกล่องพอสมควร มันจึงเป็นทางออกที่สมเหตุสมผล และถ้าไม่นับเวลาออกแบบ ก็ทำได้เพราะเป็นงานอาสาสมัคร
ปัญหาดูเหมือนจะเกี่ยวข้องกับ NAND อยู่พอสมควร และเท่าที่จำได้มันต่างจาก RouterBoard รุ่นอื่นที่รองรับอยู่บางอย่าง
มีคนเสนอวิธีแก้ใหม่สำหรับปัญหานี้แล้ว แต่ยังไม่ถูกนำไปรวม: https://forum.openwrt.org/t/wiki-cleanup-for-mikrotik-rb2011... และเธรดอื่น ๆ