Khi quản lý bộ chuyển mạch Ethernet công nghiệp lớp 3, cần phân biệt “có quản lý được thiết bị hay không” với “các dịch vụ có được chuyển tiếp đúng hay không”. Việc đăng nhập được vào trang web chỉ có nghĩa là đường truy cập quản lý này có thể truy cập được; không thể chứng minh tất cả VLAN, tuyến, chặng kế tiếp và quy tắc truy cập đều bình thường. Khi xử lý sự cố, cần thu thập bằng chứng theo đường đi thực tế của dịch vụ, sau đó thực hiện các thay đổi có phạm vi nhỏ và có thể hoàn tác, thay vì cứ mất kết nối là khởi động lại thiết bị.
1. Truy cập quản lý và dữ liệu dịch vụ đi theo các đường khác nhau
Khi máy tính quản lý truy cập địa chỉ quản lý của bộ chuyển mạch, điểm cuối dữ liệu là dịch vụ quản lý của chính thiết bị; khi thiết bị đầu cuối tại hiện trường truy cập máy chủ thuộc mạng con khác, dữ liệu phải được thiết bị chuyển tiếp ra ngoài. Hai loại lưu lượng này có thể đi qua các VLAN, quy tắc và giao diện khác nhau. CPU có thể phản hồi yêu cầu quản lý không có nghĩa là đầu ra dịch vụ hoạt động bình thường; việc truy cập quản lý bị gián đoạn cũng không nhất thiết có nghĩa là toàn bộ hoạt động chuyển tiếp bằng phần cứng đồng thời dừng lại.
Trước tiên, xác định sự cố ảnh hưởng đến một dịch vụ, một mạng con hay toàn bộ địa điểm; ghi lại nguồn, đích, thời điểm xảy ra và sự cố có liên tục hay không. Không nên chỉ mô tả hiện tượng là “mạng bị mất”. Phân quyền cho các tài khoản quản lý để tránh nhiều người đồng thời sửa cùng một cấu hình; ưu tiên các phương thức quản lý an toàn mà mẫu thiết bị được bàn giao hỗ trợ và không để mạng không đáng tin cậy truy cập các dịch vụ truy cập từ xa dạng văn bản thuần.
2. Nếu giao tiếp giữa các mạng con thất bại, trước tiên hãy kiểm tra khả năng kết nối
Thiết bị đầu cuối cần có địa chỉ, mặt nạ mạng và cổng mặc định chính xác, còn cổng truy nhập cần đưa lưu lượng vào đúng phạm vi lớp 2. Giao diện lớp 3 tương ứng phải ở trạng thái sử dụng được và thiết bị cũng cần có tuyến khớp với đích. Nếu các điều kiện cơ bản này chưa được đáp ứng, việc thay đổi mức ưu tiên hàng đợi hoặc bật thêm chức năng quản lý sẽ không giải quyết được vấn đề.
Sau khi bảng định tuyến có đường đến đích, vẫn cần kiểm tra việc phân giải chặng kế tiếp và đầu ra. Chặng kế tiếp là thiết bị láng giềng mà gói tin cần được chuyển giao tại bước hiện tại, không nhất thiết là máy chủ cuối cùng; IPv4 thường thiết lập ánh xạ giữa IP và MAC của láng giềng thông qua ARP. Khi phân giải thất bại, có thể cần kiểm tra liên kết cục bộ và cấu hình, không nên lập tức thêm một tuyến mặc định khác vì điều đó có thể che lấp triệu chứng thành một vấn đề đường đi phức tạp hơn.
Đối chiếu đầu vào, đường đến đích, chặng kế tiếp, quy tắc truy cập và trạng thái đầu ra trong cùng một khoảng thời gian, sau đó kiểm tra đường về từ máy chủ. Các quy tắc kiểm soát truy cập thông thường có thể chỉ cho phép một chiều, và cơ chế bảo vệ của chính thiết bị đầu cuối hoặc máy chủ cũng có thể từ chối yêu cầu. Nghi ngờ bộ chuyển mạch có lỗi cần có bằng chứng hỗ trợ; không nên kết luận chỉ dựa vào một lần ứng dụng hết thời gian chờ.
3. Xem biến thiên bộ đếm, không chỉ tổng tích lũy
Thống kê cổng thường lưu số byte, số gói tin và các số đếm lỗi hoặc loại bỏ khác nhau dưới dạng tích lũy. So sánh biến thiên giữa hai thời điểm lấy mẫu giúp giải thích rõ hơn những gì xảy ra trong thời gian có sự cố. Số lỗi tích lũy lớn có thể xuất phát từ rất lâu trước đó, trong khi một số ít lỗi đang tiếp tục tăng ở hiện tại cũng có thể đáng chú ý hơn. Trước tiên phải đối chiếu đúng chỉ số giao diện, cổng thực tế và chiều đo; không so sánh các giá trị của hai cổng khác nhau.
Trong ví dụ minh họa, số byte của cùng một đầu ra tăng 125,000,000 byte trong 10 giây. Nhân mức tăng với 8 rồi chia cho 10 để được tốc độ trung bình khoảng 100 Mbit/s. Đây là giá trị trung bình trong khoảng thời gian này, không phải giá trị đỉnh và không bằng thông lượng hữu ích của ứng dụng. Nếu thiết bị khởi động lại, bộ đếm bị xóa hoặc xảy ra gián đoạn bộ đếm, không thể trực tiếp coi chênh lệch này là tốc độ thực tế; với các cổng tốc độ cao, cũng cần kiểm tra độ rộng bit của bộ đếm và cách công cụ xử lý.
4. Phân biệt lỗi, loại bỏ và hết thời gian chờ của ứng dụng
Nguyên nhân gây lỗi nhận trên liên kết và loại bỏ ở đầu ra không giống nhau. Loại thứ nhất có thể liên quan đến truyền dẫn vật lý, giao diện hoặc khung; loại thứ hai còn có thể liên quan đến tắc nghẽn, quy tắc, tài nguyên hoặc định nghĩa thống kê riêng của từng mẫu thiết bị. Trước tiên hãy đọc định nghĩa cụ thể của bộ đếm, sau đó đối chiếu với thông tin mô-đun quang, tốc độ cổng, hàng đợi và nhật ký. Không thể tự động kết luận cáp bị hỏng chỉ vì thấy một lần “loại bỏ”.
Mức sử dụng cổng trung bình thấp cũng không thể chứng minh rằng không có hiện tượng lưu lượng tăng vọt gây xếp hàng. Khi cần và trong điều kiện được phép, hãy tăng tần suất lấy mẫu hoặc sử dụng biện pháp bắt gói phù hợp, nhưng lưu lượng quan sát được sao chép qua phản chiếu cổng cũng chịu giới hạn về dung lượng và phạm vi lựa chọn. Nếu cổng phản chiếu không bắt được gói tin, có thể chính quá trình phản chiếu đã bỏ sót; không thể khẳng định dịch vụ gốc không gửi gì nếu chưa kiểm tra chéo.
5. Cách các chức năng quản lý của Feichang Technology trở thành bằng chứng bảo trì
Feichang Technology Bộ chuyển mạch công nghiệp có quản lý, lắp thanh ray, 10G, 4 cổng quang, 8 cổng đồng, lớp 3 Phần thông tin chi tiết liệt kê truy cập quản lý, thống kê cổng, nhật ký, thông tin mô-đun quang và các chức năng lớp 3 tương ứng, có thể dùng để lập hồ sơ bảo trì về trạng thái thiết bị và đường đi dịch vụ. Các trường thực sự đọc được, chu kỳ làm mới và phương thức cảnh báo phải căn cứ vào mẫu thiết bị được bàn giao, firmware và tài liệu hướng dẫn; định nghĩa MIB của bên thứ ba không thể chứng minh rằng mọi mục đều được hỗ trợ.
Lưu cùng nhau bản sao lưu cấu hình, trạng thái đồng bộ thời gian, định danh cổng và phiên bản firmware để những người khác nhau có thể đối chiếu cùng một sự cố. Khi thời gian nhật ký và thời gian bắt gói không nhất quán, trước tiên hãy hiệu chỉnh mối tương quan thời gian giữa các bằng chứng để tránh ghép những sự kiện khác nhau thành một nguyên nhân. Không tùy tiện xóa các bản ghi lỗi gốc chỉ để làm đẹp số liệu trên bảng điều khiển.
6. Tối ưu hóa phải là một thay đổi được kiểm chứng
Sau khi hình thành giả thuyết rõ ràng, mỗi lần chỉ thay đổi một mục cấu hình có căn cứ và ghi lại hiệu năng dịch vụ cùng trạng thái thiết bị trước và sau khi sửa đổi. Khi liên quan đến tuyến, VLAN hoặc quy tắc truy cập, hãy bố trí khung thời gian thay đổi được phê duyệt và phương án hoàn tác; không tùy tiện tắt giao thức hoặc mở rộng quyền truy cập trong mạng điều khiển đang vận hành. Khởi động lại có thể tạm thời làm thay đổi triệu chứng, nhưng sẽ làm mất bằng chứng quan trọng tại hiện trường.
Khi nghiệm thu, không chỉ kiểm tra trang quản lý mà còn phải xem dịch vụ ban đầu bị lỗi đã phục hồi chưa, dịch vụ vốn bị hạn chế có còn bị hạn chế không, cũng như đường về và kênh quản lý có còn nguyên vẹn không. Giải thích được trạng thái bất thường nằm ở đoạn nào, đã xác minh ra sao, đã khắc phục thế nào và đã tái hiện kết quả bằng cách nào đáng tin cậy hơn việc nói chung chung rằng mạng đã được tối ưu hóa thông minh.
Ghi chú tham khảo: Bộ đếm giao diện và cách xử lý gián đoạn tham khảo RFC 2863 . Các hình là sơ đồ nguyên lý chung, các ví dụ không phải số đo của mẫu thiết bị và cần đối chiếu định nghĩa bộ đếm cụ thể với tài liệu thiết bị.
Được dịch từ bài viết kỹ thuật tiếng Trung. Nguồn xuất bản lần đầu: 2024-03-06. Nguồn sửa đổi lần cuối: 2026-10-13T11:20:43+08:00. Đọc nguồn tiếng Trung
