Cáp và interface: đọc trạng thái để tìm lỗi kết nối
Lần theo đường cáp, đọc trạng thái và counters ở cả hai đầu. Phân biệt CRC, output drops và mismatch để chọn phép thử ít tác động, có thể đối chiếu.
Người dùng báo sao chép file lúc nhanh lúc chậm. Ping vẫn có phản hồi, CPU server thấp và port switch hiện màu xanh. Nếu bỏ qua lớp vật lý vì “đèn vẫn sáng”, đội hỗ trợ có thể mất nhiều giờ đổi DNS hoặc tăng timeout. Link up chỉ xác nhận một phần trạng thái liên kết; nó chưa chứng minh tín hiệu sạch, tốc độ đúng hay không có lỗi nhận frame.
Bài này theo một đường Ethernet từ máy người dùng qua patch cord, ổ cắm tường, patch panel tới switch. Ta đối chiếu cáp đồng với quang, đọc interface counters và chọn phép thử ít tác động trước. Các tên port và số đếm là ví dụ biên tập, không phải báo cáo đo trên một tủ mạng thật.
1. Vẽ đủ đường vật lý trước khi thay sợi cáp đầu tiên
Một đường “PC nối switch” thường có nhiều đoạn: NIC, patch cord bàn, ổ cắm, permanent link trong tường, patch panel và patch cord tủ rack. Nếu chỉ thay dây tại bàn mà lỗi giữ nguyên, chưa thể kết luận toàn tuyến cáp không có vấn đề. Cần ghi mã ổ cắm, port panel, switch và interface để mỗi phép thử có vị trí rõ.
Cáp xoắn đôi đồng và cáp quang có cách truyền, giới hạn và thiết bị đầu cuối khác nhau. Với đồng, category, chiều dài channel, chất lượng đầu nối và việc dùng đủ cặp ảnh hưởng mode được hỗ trợ. Quy tắc 100 m thường được nhắc cho một số Ethernet twisted-pair channel tiêu chuẩn, không phải giới hạn chung cho mọi loại đồng hoặc mọi tốc độ.
Với quang, phải biết single-mode hay multimode, chuẩn transceiver, bước sóng, connector, số sợi và ngân sách quang. Hai đầu cùng cắm vừa một loại đầu nối chưa chứng minh tương thích. Một module cùng form factor SFP cũng không mặc nhiên chạy được ở mọi port hoặc với mọi cáp. Kiểm tra ma trận hỗ trợ và datasheet của đúng model.
Cuộn ngang khi cần, hoặc chạm sơ đồ để mở ảnh gốc.
Không nhìn trực tiếp vào đầu sợi quang hoặc transceiver đang hoạt động. Khi nghi bẩn connector, dùng quy trình kiểm tra và làm sạch phù hợp thay vì lấy tay lau. Đổi sợi quang hoặc tháo module trên uplink có thể ngắt nhiều người dùng; xác định chủ sở hữu và đường dự phòng trước thao tác.
2. Tách trạng thái quản trị, tín hiệu và trạng thái giao thức
Trên router IOS, administratively down cho biết interface bị shutdown theo cấu hình. Nó khác việc interface được phép hoạt động nhưng không phát hiện link. Trạng thái line protocol còn phụ thuộc loại interface và các điều kiện lớp liên kết. Không áp một bảng diễn giải serial đời cũ lên mọi port Ethernet hoặc SVI.
Trên switch Catalyst, trạng thái như connected, notconnect và err-disabled có ý nghĩa riêng. Err-disabled là cổng bị cơ chế bảo vệ đưa ra khỏi hoạt động, có thể liên quan vi phạm hoặc điều kiện lỗi. Chỉ gõ shutdown/no shutdown mà chưa đọc nguyên nhân có thể làm lỗi lặp lại hoặc bỏ qua một sự kiện đáng điều tra.
Hướng dẫn xử lý port/interface của Cisco giúp đọc các nhóm trạng thái và lỗi. Tài liệu có ví dụ nhiều thế hệ thiết bị; tên lệnh và trường dữ liệu cần đối chiếu với nền tảng đang dùng. Không kết luận một giá trị mặc định của Catalyst cũ áp dụng cho mọi IOS XE hiện hành.
SVI có thể phụ thuộc trạng thái VLAN và các port liên quan, còn một port Layer 3 vật lý có điều kiện khác. Nếu đầu ra là VLAN 10 thay vì GigabitEthernet, trước hết xác định bạn đang quan sát interface logic hay interface mang tín hiệu. IP trên SVI không biến nó thành nơi có một sợi cáp riêng.
3. Kiểm tra speed/duplex ở cả hai đầu
Auto-negotiation là cơ chế để hai đầu đạt các thông số phù hợp khi cả chuẩn và thiết bị hỗ trợ. Một cấu hình cố định ở một đầu và tự động ở đầu kia có thể dẫn tới kết quả không mong muốn trong một số mode, đặc biệt các tình huống 10/100 cũ. Vì vậy, ép full duplex ở một phía không phải mẹo tăng tốc vô điều kiện.
Tài liệu auto-negotiation của Cisco phân tích mode 10/100/1000 và triệu chứng mismatch. Với 1000BASE-T, negotiation phục vụ các yêu cầu của liên kết; không sao chép cách ép half/full từ 100BASE-TX để giải thích mọi mode gigabit hoặc quang.
Ghi cùng thời điểm tốc độ và duplex ở NIC lẫn switch. Nếu một phía ghi 100 Mbps, chưa thể hứa chỉ đổi setting là lên 1 Gbps. Có thể thiết bị chỉ hỗ trợ 100, cáp không đủ cặp hoặc không đạt chất lượng, hay port có cấu hình giới hạn. Xác minh khả năng phần cứng và tuyến cáp trước.
Thông báo duplex mismatch từ CDP là một dữ kiện so sánh thông tin neighbor, không phải chính bản tin auto-negotiation. Nó hữu ích nhưng còn phụ thuộc CDP và dữ liệu hai bên. Không thấy cảnh báo cũng không bảo đảm mọi thông số đúng; cần đọc trực tiếp trạng thái thực tế.
Cuộn ngang khi cần, hoặc chạm sơ đồ để mở ảnh gốc.
4. Đọc counters theo khoảng thời gian, không theo một con số đứng yên
CRC/FCS error tại phía nhận cho biết frame đến có kiểm tra lỗi không khớp theo cách nền tảng ghi nhận. Nó gợi ý vấn đề trên đường truyền hoặc thành phần liên quan, nhưng một con số không xác định được chính xác dây, NIC, module hay port nào hỏng. Có thể cần quan sát tại nhiều điểm để tìm nơi lỗi bắt đầu.
Tài liệu CRC của Cisco Nexus cho thấy cách hiểu lỗi và các điều kiện theo nền tảng. Không trộn mọi chi tiết xử lý frame của Nexus với Catalyst; nguyên tắc đối chiếu FCS có thể dùng để hiểu, còn counters và cơ chế chuyển tiếp cần đọc theo thiết bị.
Ví dụ port nhận 20 CRC lúc 09:00 và 120 lúc 09:05. Delta là 100 trong 300 giây. Nếu cùng kỳ tổng frame nhận tăng một triệu, tỉ lệ lỗi quan sát cho chỉ số này là 0,01%. Đây chỉ là tính toán minh họa; không có ngưỡng “0,01% là chấp nhận” áp cho mọi dịch vụ hay thiết bị.
Kiểm tra thời điểm counters được reset, reboot hoặc wrap trước khi lấy hiệu. Nếu số mới nhỏ hơn số cũ, trừ máy móc sẽ ra tốc độ âm vô nghĩa. Cũng không cộng CRC, input errors và các mục con rồi gọi là số frame lỗi riêng biệt; một frame có thể tác động nhiều counter tùy cách ghi nhận.
Cuộn ngang khi cần, hoặc chạm sơ đồ để mở ảnh gốc.
Output drops có thể liên quan hàng đợi và tắc nghẽn, không đồng nghĩa tín hiệu cáp hỏng. Late collision có thể gợi ý mismatch hoặc vấn đề trong ngữ cảnh half-duplex phù hợp. Cần phân biệt nguyên nhân vật lý, lớp liên kết và tải; đổi cáp không giải mọi tình huống drop.
5. Thu thập bằng lệnh đọc trước khi reset hoặc đổi cấu hình
Trên thiết bị IOS/IOS XE phù hợp, bắt đầu bằng các lệnh dưới đây. Gi1/0/10 chỉ là tên ví dụ; dùng tên port đã đối chiếu từ sơ đồ và kiểm tra trợ giúp nếu model khác. Không chạy lệnh thay đổi chỉ vì một lệnh show không được hỗ trợ.
show interfaces status
show interfaces GigabitEthernet1/0/10
show interfaces counters errors
show loggingshow interfaces status thường gặp trên switch, không phải lệnh bắt buộc tồn tại trên mọi router. Lệnh log có thể chứa thông tin nội bộ; lọc thời gian/interface liên quan và biên tập trước khi chia sẻ. Tránh bật debug diện rộng trong bước thu thập đầu vì có thể tạo tải và nhiều dữ liệu khó đọc.
Nếu transceiver hỗ trợ giám sát số và thiết bị cung cấp lệnh tương ứng, có thể xem mức Tx/Rx theo ngưỡng của đúng module. Một giá trị dBm chỉ có ý nghĩa khi biết ngưỡng, đơn vị và chiều đo. Không so số âm bằng trực giác “càng gần 0 luôn càng tốt”; công suất vượt ngưỡng cũng có thể là vấn đề.
Trên Windows, đọc tốc độ link tại adapter hoặc dùng Get-NetAdapter trong PowerShell; trên Linux xem thông tin được driver cung cấp qua công cụ phù hợp như ethtool. Các con số này là link rate, không phải cam kết tốc độ sao chép file. Protocol, storage và tải ứng dụng còn ảnh hưởng throughput.
6. Thiết kế phép thử thay một biến và ghi đường quay lại
Bắt đầu bằng thao tác không gián đoạn: xác nhận thời điểm lỗi, số người ảnh hưởng, route đang dùng, log flap và sự tăng counters. Nếu có thể, so port lỗi với một port tương tự đang hoạt động nhưng giữ nguyên điều kiện quan sát. Không so một NIC đang idle với uplink đầy tải rồi suy ra cáp bên nào tốt hơn.
Khi cần thay patch cord, ghi nhãn và baseline trước; thực hiện trong phạm vi được phép rồi đo lại cùng thời lượng. Nếu chuyển sang port khác, phải kiểm tra VLAN, PoE, port security và profile trước. Một lần chuyển port đồng thời đổi VLAN và thay dây không chỉ ra thành phần nào là nguyên nhân.
Rút cáp, bounce port hoặc đổi speed có thể ngắt phiên người dùng, điện thoại PoE, AP hay đường quản trị. Nêu tác động ngay trong kế hoạch thao tác và giữ cách khôi phục. Không bounce uplink từ xa nếu chưa có đường dự phòng hoặc người tại chỗ có thể đưa mạng trở lại.
Kiểm tra thành công cần nhiều hơn một ping: counters không tăng bất thường trong kỳ theo dõi phù hợp, link không tiếp tục flap, tốc độ đúng thiết kế và thao tác người dùng hồi phục. Không dùng kết quả thử một phút để cam kết lỗi gián đoạn theo chu kỳ một giờ đã được loại trừ.
7. Giao lại bằng chứng thay vì kết luận “đã thay dây”
Ticket nên ghi tuyến vật lý, port, trạng thái hai đầu, snapshot counters và thời điểm, các thay đổi đã làm, kết quả sau thay và hiện tượng còn lại. Nếu cần đội hạ tầng đo chứng nhận permanent link hoặc kiểm tra module, dữ liệu này giúp họ đi thẳng tới đoạn liên quan thay vì bắt đầu lại.
Hãy tự giải thích vì sao CRC tăng khác output drops, vì sao link 100 Mbps chưa chứng minh cáp đứt và vì sao phải đọc cả hai đầu khi nghi mismatch. Nếu kết luận cần từ một counter duy nhất, thử nêu một nguyên nhân thay thế trước. Sau khi nền vật lý ổn, bài IOS và SSH sẽ hướng dẫn cấu hình quản trị có kiểm soát để các phép kiểm tra tiếp theo không phụ thuộc truy cập tạm bợ.