Cắm SFP vào các cổng 24-28 trên DGS-1210-28 chạy OpenWrt chẳng thay đổi gì, cổng đồng vẫn giữ link
Switch homelab: một con D-Link DGS-1210-28 revision F1 mà mình đã flash OpenWrt lên để khỏi phải vật lộn với web UI gốc. Mọi thứ đều chạy tốt trừ bốn cổng cuối, là mấy cổng combo đồng/quang.
- Switch: D-Link DGS-1210-28 rev F1
- Firmware: OpenWrt 21.02.0-rc3 (r16172-2aba3e9784)
- Cổng 24-28: combo RJ45/SFP đứng sau PHY RTL8214FC (các cổng còn lại nằm trên RTL8218B/RTL8218D)
- Module: một con quang 1G generic vẫn lên link bình thường trên switch khác
Dù cắm gì vào cage, cổng vẫn cư xử như một cổng RJ45 bình thường. Phía đồng cứ được chọn sẵn, còn phía quang thì không bao giờ lên:
# ethtool lan28
Supported ports: [ TP MII FIBRE ]
Port: MII
Link detected: yesLog boot thì có cho thấy mấy cổng này được gắn với driver PHY combo RTL8214FC, và driver đó lẽ ra phải biết về SFP, nên phần cứng có vẻ ổn.
Đã thử tới giờ:
- rút ra cắm lại module, rồi thử thêm một con thứ hai
- rút hẳn dây đồng ra khỏi cổng phòng trường hợp đây là chuyện ưu tiên: cổng vẫn ở trên đồng
- chuyển module sang một switch khác, và nó lên link ở đó
Với firmware gốc của hãng, con switch này từng tự động chuyển cổng sang quang ngay khi có module cắm vào. Có cách nào chọn medium trên bản build này không, hay là mấy cổng combo đơn giản là chưa dùng được?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 3
Không có gì hỏng cả, chỉ là target realtek này không có tính năng tự động chọn medium. RTL8214FC là một PHY combo với một nửa đồng và một nửa quang, và trên firmware này nó cứ nằm ở phía MII/đồng cho tới khi có gì đó bảo nó đổi. Cắm module vào chẳng có ý nghĩa gì với driver cả, vì chưa ai viết phần chuyển đổi này.
Bạn tự chọn medium từ userspace:
Sau đó cage sẽ là medium đang hoạt động trên cổng đó và quang sẽ lên. Để trả cổng lại cho nửa RJ45:
Gọi lệnh tương tự cho từng cổng combo còn lại, mỗi cổng một lần.
Cái bạn nhớ từ firmware gốc là một kiểu auto-select giới hạn: nó nhìn cả hai nửa, và đồng thắng bất cứ khi nào cả hai đều có link. Đó là lý do chuyện này đọc như một regression, nhưng không phải: chức năng đó đơn giản là chưa từng được viết cho target này.
Hai điều cần lưu ý. Nó chỉ có ở CLI, không được đưa lên LuCI, và người ta đã hỏi xin tính năng đó khá lâu rồi. Và không có gì trên bản build này tự chọn medium giúp bạn cả, nên nếu muốn có quang sau mỗi lần boot, phải đảm bảo lệnh đó thực sự được chạy.
Đúng là nó luôn, cảm ơn bạn. Một lệnh và cổng chuyển ngay:
Quang lên ngay lập tức và nửa RJ45 im hẳn. Mình làm tương tự cho ba cổng combo còn lại và đưa bốn lệnh đó vào một startup script, vì đúng như bạn nói, chẳng có gì nhớ lựa chọn này cả.
Hơi khó chịu một chút khi một cái toggle từng cổng lại phải nằm trong shell script, nhưng giờ các cổng đã dùng được, đó là điều mình cần.
Đáng biết trước khi bạn dựng monitoring trên mấy cổng đó: trạng thái link ở phía SFP của mấy board này không phải lúc nào cũng đáng tin. Trên DGS-1210-10P, device tree hoàn toàn không có node sfp nào cả, nên kernel không bao giờ nhận được module-present hay loss-of-signal, và MAC báo cáo carrier thường trực:
ip linkin ra<BROADCAST,MULTICAST,UP,LOWER_UP>cho lan9 dù cage đang trống, và nó vẫn cứ up ngay cả khi cắm một SFP đồng GLC-T-CO mà không có dây nhảy nào trong đó. DGS-1210-10MP không bị vậy, vì DTS của nó đã có sẵn các node đó rồi.Cách sửa ở đó là một thay đổi device tree dựa theo mẫu của 10MP và của Zyxel GS1900-10HP: một bus i2c-gpio cho mỗi cage, một node sfp cho mỗi cage với los-gpio, mod-def0-gpio và tx-disable-gpio,
sfp = <&sfp0>được tham chiếu từ cổng,phy-mode = "1000base-x"vàmanaged = "in-band-status". Có những thứ đó vào rồi thì cage được probe qua I2C, và carrier cuối cùng cũng bám theo đúng tín hiệu quang thực tế.Trên các image gốc của giai đoạn đó, hành vi này vẫn còn nguyên, nên nếu có gì của bạn đang theo dõi carrier trên một cổng combo hay SFP, hãy kiểm tra xem nó có thực sự rớt khi bạn rút sợi quang ra hay không.