Tự chế tạo switch mạng do Linux quản lý

 (blog.brixit.nl)
1 điểm bởi GN⁺ 2024-07-05 | 1 bình luận | Chia sẻ qua WhatsApp
  • Để tái hiện kiến trúc mà Linux trực tiếp điều khiển chip switch như bên trong router tiêu dùng, tác giả đã thiết kế một PCB switch gigabit dựa trên RTL8367S và kết nối nó với DSA/switchdev
  • RTL8367S được chọn là chip switch gigabit 7 cổng với PHY tích hợp trên 5 cổng; thay vì dùng cổng CPU chuyên dụng, cổng 0 được nối bằng cáp mạng tới Ethernet của bo Linux
  • Trong quá trình làm phần cứng, các đường nguồn được đơn giản hóa còn 3.3V và 1.1V, đồng thời thử nghiệm các đường cấu hình như chân thiết lập lúc khởi động, EEPROM, SPI flash và cổng serial
  • Để kết nối với Linux cần bo PINE64 A64-lts, các tùy chọn kernel tùy chỉnh và chỉnh sửa Device Tree; sau khi khởi động, lan1~lan4 xuất hiện dưới eth0 như các giao diện mạng cục bộ
  • Cách làm này tương thích tốt với các công cụ sẵn có như Linux bridge và ethtool, nhưng khó dùng ngay trên PC/server phổ thông hay giao diện mạng USB do các ràng buộc về Device Tree và GPIO

Switch được quản lý và kiến trúc Linux DSA

  • Switch được quản lý thông thường cho phép thay đổi cấu hình và xem trạng thái cổng qua giao diện web; thiết bị đắt tiền hơn còn cung cấp thêm các giao diện như telnet hoặc console serial
  • Switch bên trong router tiêu dùng cũng có thể được xem là một dạng switch được quản lý riêng
    • Router là một thiết bị Linux nhỏ có chứa chip switch bên trong
    • Một hoặc nhiều cổng được nối nội bộ tới CPU, còn các cổng khác được đưa ra ngoài dưới dạng cổng vật lý
  • Dùng các phân hệ DSA và switchdev của Linux, các cổng nối với switch có thể hoạt động như những cổng mạng “cục bộ” thực sự
  • Giữa SoC router và switch cần có kết nối như SGMII hoặc RGMII cùng bus quản lý như SMI hoặc MDIO
  • Các switch thương mại thông thường không đưa các kết nối chip cần thiết này ra ngoài, nên khó điều khiển theo cách đó

Chế tạo bo switch dựa trên RTL8367S

  • Switch gigabit tự làm sử dụng chip Realtek RTL8367S
    • Đây là chip switch gigabit 5 cổng được dùng khá rộng rãi
    • Thực tế nó có cấu trúc 7 cổng, trong đó 5 cổng có PHY tích hợp và 2 cổng dành cho kết nối CPU
  • Do datasheet chỉ cung cấp thông tin tối thiểu, tác giả phải tham khảo thêm sơ đồ mạch của các thiết bị dùng chip Realtek tương tự và tài liệu thiết kế Ethernet
  • Ban đầu có vẻ cần khoảng 7 mạng nguồn, nhưng vì các dải điện áp chồng lấp nhau nên có thể gộp lại để chỉ dùng bộ ổn áp 3.3V và 1.1V
  • Vì Linux switchdev không bắt buộc kết nối CPU phải là cổng CPU chuyên dụng, thiết kế này nối cổng 0 bằng cáp tới bo Linux
    • Từ góc nhìn của driver switchdev, trông như không có Ethernet PHY ở giữa

Cấu hình chip switch và những lần thử sai trên PCB

  • RTL8367S có nhiều đường cấu hình khác nhau, nhưng chỉ dựa vào datasheet thì khó xác định cấu hình tối thiểu để nó hoạt động như một dumb switch thông thường
    • 8 chân được đọc lúc khởi động dùng chung với chân LED cổng
    • Bus i2c có thể dùng để nối chip EEPROM nhưng lại dùng chung chân với bus SMI cần thiết
    • Bus SPI có thể nối NOR flash để lưu thanh ghi cấu hình hoặc firmware cho lõi 8051 tích hợp
    • Cổng serial được cho là sẽ không hoạt động nếu không có firmware 8051
  • Với bo đầu tiên, tác giả đặt hàng trước rồi thay đổi các mối hàn để tìm điều kiện hoạt động
    • Có thêm footprint cho chip flash nhưng cuối cùng không cần dùng
    • Các chân cấu hình được làm bằng solder jumper
    • LED bị loại bỏ vì khó làm cho có thể cấu hình được
  • Tài liệu thiết kế Gigabit Ethernet thường nhấn mạnh kiểm soát trở kháng và cân bằng chiều dài rất chính xác, nhưng thiết kế của các switch giá rẻ thực tế có vẻ không nghiêm ngặt đến vậy
  • Phần được xem là quan trọng hơn là cân chỉnh skew giữa các cặp mạng
    • Tác giả cho rằng việc làm cho toàn bộ 4 cặp mạng có cùng chiều dài với nhau không thực sự hữu ích
    • Ngay trong cáp mạng, tỉ lệ xoắn của 4 cặp cũng đã khác nhau đáng kể nên chiều dài vốn đã chênh lệch nhiều
  • Ở bản bo đầu tiên, Ethernet không hoạt động do xử lý sai tụ điện tham chiếu điểm giữa transformer phía switch xuống mass
    • Khi thử nghiệm, một đường mạch nhỏ đã được cắt để bỏ hiện tượng chập mass
    • Trong cấu hình thử nghiệm, điểm giữa vẫn hoạt động dù bị thả nổi
    • Ở thiết kế cuối cùng, tụ điện đó đã được thêm vào

Switch hoàn chỉnh và kết nối với Linux

  • Bo hoàn chỉnh là một switch gigabit có hình dạng hơi khác thường
    • 4 cổng hướng về một phía
    • 1 cổng hướng về phía đối diện và được dùng để nối với bo Linux
    • Nguồn được cấp qua pin header 2.54mm
    • Cũng có thêm footprint đầu nối USB Type-C để cấp nguồn mà không cần dây DuPont
  • Bo Linux dùng để thử nghiệm là PINE64 A64-lts
    • Vị trí đầu nối của nó khá phù hợp với bố trí mong muốn
    • Vì cần thay đổi Device Tree nên việc dùng nền tảng không phải x86 là quan trọng
  • Kernel được build lại vì các module liên quan đến switch thường không được bật sẵn
    • CONFIG_NET_DSA: Distributed Switch Architecture
    • CONFIG_NET_DSA_TAG_RTL8_4: gắn thẻ cổng cho chip switch Realtek
    • CONFIG_NET_SWITCHDEV: hệ thống driver switch mạng
    • CONFIG_NET_DSA_REALTEK, CONFIG_NET_DSA_REALTEK_SMI, CONFIG_NET_DSA_REALTEK_RTL8365MB: driver cho chip switch thực tế
  • Thay vì nạp Device Tree overlay bằng U-Boot, tác giả vá trực tiếp Device Tree của bo A64-lts
    • Dùng chuỗi tương thích realtek,rtl8365rb để nạp driver
    • Driver này hỗ trợ nhiều chip switch Realtek, bao gồm cả RTL8367S được sử dụng
    • Phần định nghĩa cổng CPU trong ví dụ tài liệu được bỏ đi và thay bằng định nghĩa 5 cổng switch thông thường
  • port@0 là cổng quay ra phía sau và được nối với &emac của A64-lts
    • Các cổng còn lại được nối tới từng PHY bên trong chip switch
    • Phần đầu Device Tree định nghĩa 3 GPIO nối với SDA/SCL và Reset

Công cụ mạng Linux và các giới hạn

  • Sau khi khởi động, Linux hiển thị thiết bị eth0 thông thường cùng các giao diện cổng switch được định nghĩa trong Device Tree
    • lan1@eth0
    • lan2@eth0
    • lan3@eth0
    • lan4@eth0
  • Để vận hành thực tế cần chạy ip link set eth0 up và bật từng giao diện lan
  • Việc kết hợp với các công cụ mạng Linux tiêu chuẩn diễn ra tự nhiên
    • Khi thêm nhiều cổng lan vào Linux bridge, switchdev sẽ xử lý việc bridge các cổng đó ngay trong chip switch
    • Linux không cần trực tiếp chuyển tiếp lưu lượng đó
    • Có thể xem thông tin link bằng ethtool lan3
    • ethtool -S lan3 trả về thông tin trạng thái tiêu chuẩn, bao gồm cả các gói được switch xử lý hoàn toàn
  • Tuy vậy, cách này có nhiều giới hạn nếu muốn dùng trong môi trường phổ thông
    • Phải tự làm switch mạng hoặc mở một switch có sẵn để tìm các kết nối cần thiết
    • PC hoặc server thông thường không dùng cấu hình dựa trên Device Tree, và cũng thường không có các chân GPIO do kernel điều khiển để sử dụng
    • Giao diện mạng USB khó dùng theo cách này vì không có node handle trong Device Tree để chỉ định làm conduit port
  • Một số hạn chế có thể lách được, nhưng sẽ cần thêm nhiều tài liệu về cách nạp switchdev trong môi trường không phải thiết bị ARM hoặc dùng thiết bị USB đặc biệt có xuất GPIO

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-07-05
Ý kiến trên Hacker News
  • Có thể nhìn theo kiểu “switch mạng là thiết bị đơn giản, gói tin chỉ đi vào rồi đi ra; may thay, con người đã tìm ra cách làm nó phức tạp hơn và phát minh ra switch có quản lý”, nhưng các switch đắt tiền có ASIC khá tinh vi bên trong
    Ví dụ, một cặp switch Dell OS9 cũ là thiết bị stack đời cũ có 48 cổng 10Gb/s và 4 cổng quang QSFP+ 40Gb/s, mỗi switch có thể xử lý tối đa 1,28Tb/s
    Ngày nay có thể mua được với giá khoảng £1800 đã gồm VAT và gần như dùng được mãi
    Những nỗ lực như thế này rất hay, nhưng cũng cần tính đến việc những hãng như Netgear đang bán switch 8 cổng 1Gb có PoE trên mọi cổng với giá khoảng £125
    Xét về tính kinh tế của dự án, nếu tính thời gian ở mức £20~50/giờ thì hàng có sẵn có thể là lựa chọn đúng, nhưng nếu mục đích là chính dự án thì không cần bận tâm đến giá
    (1) https://i.dell.com/sites/doccontent/shared-content/data-shee...
    (2) https://www.etb-tech.com/dell-force10-s4820t-10gbe-switch-os...
    • Tôi từng làm việc với loại switch ASIC như thế này của Broadcom; không phải loại 40Gb mà là khoảng 4x10Gbps + 24x1Gbps + PCIe cho CPU
      Giá ASIC ở mức có thể dự đoán được; tôi không biết con số thực tế nhưng có lẽ vào khoảng vài trăm đô la
      Tài liệu giao diện phần mềm thì rất tệ; vì đó là thư viện hỗ trợ mọi switch ASIC của Broadcom nên một file .a nặng hàng trăm MB chứa đầy các hàm chỉ trả về lỗi “không được hỗ trợ trên thiết bị này”, và bạn không thể biết cho đến khi tự gọi thử
  • Dự án thú vị
    Với các nhu cầu đơn giản hơn, đa số có thể mua router hỗ trợ OpenWRT dùng chip switch có quản lý, và OpenWRT cung cấp giao diện tốt để cấu hình VLAN cùng nhiều tùy chọn khác
    • Ngày nay OpenWRT cũng có thể cài trên một số switch như dòng Zyxel GS1900
      Tuy nhiên hỗ trợ các tính năng như PoE hay cổng 10Gb/SFP+ có thể còn hạn chế, và hiện trạng thì tôi không chắc
  • Lần đầu tôi thấy cách dùng sáng tạo dòng switch RTL83 là ở https://spritesmods.com/?art=rtl8366sb, và sau đó cũng có vài trường hợp tương tự
    Nhưng dự án này gần với một switch có quản lý tự chế mà tôi thấy lần đầu hơn, chứ không phải kiểu “gắn bộ não bên ngoài vào switch không quản lý”
    • Đúng là sprite_tm huyền thoại; tôi từng đọc bài đó khi tự viết firmware Raspberry Pi để quản lý switch qua USB
  • Tôi tò mò nó có ưu điểm gì so với cách cắm nhiều adapter gigabit vào một máy Linux rồi đưa tất cả vào bridge
    Tôi đoán hiệu năng phía phần cứng sẽ tốt hơn, nhưng không biết đã có bài test nào cho thấy khác biệt thực tế chưa
    • Khác biệt đại khái sẽ là sự kết hợp giữa thông lượng, độ trễ, mức tiêu thụ điện và tính năng
      Nếu dùng adapter USB, vì USB về nhiều mặt là bus dùng chung nên sẽ nhanh chóng chạm trần băng thông tối đa, nhất là khi dữ liệu phải đi vào CPU rồi lại đi ra
      Chuyển mạch bằng phần mềm sẽ thêm thời gian xử lý từng gói và gửi lại đến đúng nơi, cộng thêm độ trễ của chính giao diện
      Mỗi adapter có PHY mạng và phần cứng riêng nên tiêu thụ điện tăng, cộng với xử lý bổ sung thì mức dùng điện còn lớn hơn
      Bạn cũng ít tận dụng được hardware offloading hoặc các cải thiện hiệu năng khác, khiến toàn hệ thống phải tham gia nhiều hơn vào việc di chuyển gói tin
      Về tính năng thì tùy phần cứng được chọn; một số adapter USB gigabit giá rẻ từng không hỗ trợ tốt các tính năng như VLAN
      Ngược lại, nếu dùng nhiều card PCIe thì tính năng có thể tốt hơn nhiều, nhưng từ điểm đó trở đi nó gần với routing hơn là switching
    • Nếu phần lớn lưu lượng là switching thì cách này hiệu quả hơn; nếu phần lớn cần routing thì nhiều adapter riêng sẽ hiệu quả hơn
    • Như các câu trả lời khác, cách này có khả năng dùng ít điện hơn, và độ trễ khi đi qua switch cũng sẽ thấp hơn bridge phần mềm
      Ngay cả khi host OS chết, switching vẫn có thể tiếp tục hoạt động; nếu kết hợp watchdog và cơ chế khôi phục, có thể tạo ra hệ thống có tính sẵn sàng tốt hơn bridge phần mềm, dù một số chức năng tạm thời không hoạt động
      Tuy nhiên cần giả định rằng bản thân chip switch không chết hoặc bị treo
      Tùy mục tiêu, nếu muốn kiểm tra toàn bộ lưu lượng đi qua switch thì 4 interface rõ ràng tốt hơn
      Nếu switch dựa trên host cũng giao tiếp nhiều, 4 interface cung cấp 4Gbps cho host, có lợi hơn so với một cổng 1Gbps duy nhất
      Card quad 1G doanh nghiệp đã qua sử dụng có thể mua trên eBay với giá dưới $15; tôi thích Silicom quad bypass 1g PEG4BPI-SD
      Chức năng bypass thú vị và khác thường nên nó rẻ hơn, nhưng nói chung một khi đã cấu hình như “NIC tiêu chuẩn” thì có thể cắm sang chỗ khác dùng mà không gặp vấn đề lớn
      Các sản phẩm đời đầu khó dùng hơn vì vendor và sub-vendor trong PCI ID đều hiện là Silicom; card -SD có vendor ID của Intel và sub-vendor Silicom nên driver phổ thông sẽ nhận
      Cổng 4x10G có nhiều thứ phải quản lý hơn, và tùy hệ thống host, thông lượng bridge phần mềm có thể không đủ
      Card 10G bốn cổng khó kiếm, nhưng 2x10G thì nếu chờ có thể mua được với giá hợp lý
    • Trong cách đó, CPU nằm trên đường dữ liệu
      Switch thực hiện chuyển mạch gói tin trong ASIC chứ không phải CPU, nên nếu dùng CPU thì phụ thuộc vào hiệu năng CPU và thường không phải cách sử dụng tài nguyên tính toán hiệu quả
    • Với tốc độ thấp và số cổng ít như thế này thì mạch switch phần cứng không hẳn là bắt buộc
      Dù vậy, nếu bỏ qua công sức thiết kế và chế tạo, tổng chi phí phần cứng có thể dưới $100 và có khả năng rẻ hơn một máy tính có nhiều interface
      Tuy nhiên mạng 1Gb/s đã khá cũ rồi

Có thể tạo một switch mạng quản lý được lớn hơn và nhanh hơn với chi phí chỉ hơn $200, chỉ bằng các linh kiện bán sẵn
Ví dụ, dùng Odroid H4+ có 2 cổng và một card mở rộng M.2 thêm 4 cổng Ethernet thì có thể tạo một switch 6 cổng 2.5Gb/s
Một cách khác là dùng máy tính nhỏ gọn có CPU N100 và 4 cổng 2.5Gb/s, có thể mua từ nhiều nhà sản xuất Trung Quốc trong tầm giá này
Các máy tính nhỏ gọn tương tự có 6 cổng 2.5Gb/s thì đắt hơn một chút, có thể nhỉnh hơn $300

  • Không rõ OpenFlow giờ ra sao
    Có vẻ rất hợp với các thiết bị kiểu này, nhưng gần như không thể dựng môi trường lab nên tôi mất hứng thú
    • Có thể tạo một client OpenFlow dùng chip switch này làm data plane, nhưng phần lớn các tính năng muốn dùng trong OpenFlow nhiều khả năng sẽ không tận dụng được đường nhanh phần cứng tương đối hạn chế, nên có thể không phải lựa chọn tối ưu
    • OpenFlow là một lời giải hơi sai cho vấn đề; lời giải phù hợp hơn là switchdev hoặc SAI
    • Theo tôi biết, OpenFlow cố làm quá tổng quát nên không ánh xạ tốt lên phần cứng thực tế, cuối cùng abstraction bị rò rỉ khá nhiều
  • Theo những gì tôi đọc được, khi làm switch 10Gbps, các nhà sản xuất chip tăng tốc không hỗ trợ driver mở, nên rất khó tránh phụ thuộc vào một số binary blob
    Tôi nghĩ cần các chip như vậy vì switching bằng CPU sẽ tạo tải lớn
    • Marvell 88E6393X hoạt động ở chế độ “đơn giản/quản lý ngoài” mà không cần firmware
      Có thể dùng cùng Linux switchdev như thiết bị trong bài này
  • Không rõ có hỗ trợ rSTP không
    • Có vẻ là không; hình như chỉ có STP thường và có lẽ MSTP
  • Không có ác ý, và có thể tôi đã hiểu nhầm điều gì đó
    Tác giả dùng sơ đồ khối RouterBoard làm mẫu để cho thấy switch phần cứng được kết nối với phần còn lại của hệ thống như thế nào, rồi sau đó có vẻ lại lập luận rằng những thiết bị như vậy không thể xử lý được hoặc khó xử lý
    Tôi tò mò không biết ở đây đã từng thực sự kiếm RouterBoard chưa
    Có lẽ có thể build OpenWRT cho hầu hết RouterBoard, và 2011 cũng là thiết bị khá phổ biến trên thị trường đồ cũ
    Câu hỏi hay hơn là mục tiêu ngay từ đầu có phải là tự chế từ đầu hay không, hay vì lý do cụ thể nào đó mà đã bỏ qua ý tưởng dùng phần cứng của người khác
    • Tôi có vài thiết bị như vậy; chúng rất tốt cho mục đích ban đầu, nhưng không mấy phù hợp để chạy phần mềm tùy biến
      Tôi lấy sơ đồ RB2011 vì nghĩ nó đơn giản và được giải thích rõ
      Về mặt kỹ thuật, RB1100AHx4 dùng cùng chip switch sẽ là ví dụ tốt hơn, nhưng nó lại gây rối hơn vì dùng cả hai cổng CPU cùng lúc và gọi 2 liên kết 1.25Gbps là liên kết 2.5Gbps trong khi bỏ qua overhead mã hóa
      Lý do làm từ đầu là chi phí hợp lý, và thiết bị này phải nằm trong hộp ghi hình video FOSDEM
      Cần giải quyết một số vấn đề riêng cho thiết kế đó: phải đưa 4 cổng mạng ra mặt trước case, đồng thời vẫn phải kết nối với SBC bên trong
      Bên trong case không có nhiều chỗ để đưa passthrough tới switch mà không dùng cáp loop ngoài cho SBC, còn nếu dùng switch đơn giản thì cũng không giám sát hệ thống được
      Vì chúng tôi làm khá nhiều hộp như vậy nên đây là giải pháp hợp lý; nếu bỏ qua thời gian thiết kế thì vì là công việc tình nguyện nên có thể làm được
    • RouterBoard RB2011 bị kẹt ở bản phát hành OpenWrt 19.07 cũ: https://openwrt.org/toh/mikrotik/rb2011
      Vấn đề dường như có liên quan phần nào đến NAND, và theo tôi nhớ thì nó khác gì đó so với các RouterBoard khác được hỗ trợ
      Có người đã đề xuất một cách giải quyết mới cho vấn đề này nhưng vẫn chưa được đưa vào: https://forum.openwrt.org/t/wiki-cleanup-for-mikrotik-rb2011... và các thread khác