Mất điện hoàn toàn trên Core Switch Cisco Catalyst 9300: rủi ro kẹt ở ROMmon khi mất điện giữa lúc nâng cấp firmware, và cơ chế cắt cổng có trật tự khi StackPower cạn ngân sách
Bài trước trong cụm này đã phân tích cơ chế StackPower tự phân bổ lại công suất khi một bộ nguồn bị ảnh hưởng bởi sụt áp — một cơ chế hoạt động tốt với điều kiện ngân sách công suất còn dư và switch vẫn đang chạy bình thường. Mất điện hoàn toàn đặt ra hai câu hỏi khác hẳn: thứ nhất, điều gì xảy ra nếu mất điện xảy ra đúng vào lúc switch đang thực hiện một hoạt động nhạy cảm như nâng cấp firmware — một tình huống có thể khiến switch "kẹt" ở màn hình ROMmon, không tự khởi động lại được dù điện đã có trở lại; thứ hai, điều gì xảy ra với toàn bộ các switch trong một stack khi ngân sách công suất StackPower không còn đủ để "chịu đựng" việc mất hẳn một nguồn, không chỉ bị ảnh hưởng tạm thời.
1. Mất điện hoàn toàn khác gì với sụt áp đã phân tích ở bài trước
Theo tiêu chuẩn IEEE 1159, mất điện hoàn toàn (power outage/interruption) là tình huống điện áp giảm xuống dưới 0,1 lần điện áp danh định, có thể kéo dài từ vài chu kỳ điện đến vô hạn (nếu không được khôi phục) — khác hẳn với sụt áp thoáng qua (tối đa 1 phút, biên độ 0,1-0,9 lần điện áp danh định) đã phân tích ở bài trước (IEEE 1159 — IEEE Recommended Practice for Monitoring Electric Power Quality). Với switch Catalyst 9300, sự khác biệt này quan trọng vì nó quyết định switch đang ở trạng thái nào khi nguồn bị cắt — vẫn đang hoạt động bình thường (ít rủi ro), hay đang ở giữa một quy trình ghi dữ liệu/cập nhật firmware nhạy cảm (rủi ro cao hơn hẳn).
2. Rủi ro trung tâm: mất điện giữa lúc nâng cấp firmware có thể khiến switch kẹt ở ROMmon
Đây là phát hiện kỹ thuật trung tâm của bài viết. Theo tài liệu hướng dẫn khắc phục sự cố chính thức của Cisco cho dòng Catalyst 9000 (bao gồm 9300), có nhiều tình huống khiến switch khởi động vào chế độ ROMmon (Read-Only Memory Monitor — một môi trường khởi động cấp thấp, không có hệ điều hành IOS XE đầy đủ, chỉ dùng để chẩn đoán/khôi phục) thay vì khởi động bình thường (Cisco — Recover Catalyst 9000 Switches from Upgrade Failures):
Thiếu hoặc hỏng file cấu hình
.conf: nếu switch không tìm được file cấu hình hợp lệ ở chế độ Install Mode (chế độ cài đặt phần mềm hiện đại trên IOS XE), nó sẽ mặc định rơi về ROMmon.Lỗi biến khởi động "Stack 1+1": một biến bootloader cụ thể gây ra lỗi "Active/standby selection failed in 1+1 Mode", khiến switch dừng ở ROMmon.
Biến boot không hợp lệ: khi câu lệnh boot chỉ tới phiên bản phần mềm không còn tồn tại hoặc đã cũ, thay vì image hiện tại.
Mối liên hệ với mất điện hoàn toàn nằm ở chỗ: quá trình nâng cấp firmware/cập nhật phần mềm trên switch doanh nghiệp thường bao gồm nhiều bước ghi file tuần tự (giải nén package, cập nhật file cấu hình boot, đồng bộ giữa các switch trong stack) — nếu mất điện xảy ra đúng vào giữa một trong các bước này, file đang được ghi có thể bị hỏng/không hoàn chỉnh, dẫn đến chính xác những tình huống "thiếu hoặc hỏng file .conf" hoặc "biến boot không hợp lệ" mà tài liệu Cisco đã liệt kê. Đây là một rủi ro mang tính thời điểm rõ rệt: switch hoạt động bình thường hàng ngày không gặp rủi ro này, nhưng khung thời gian ngắn khi đang nâng cấp phần mềm lại là lúc rủi ro cao nhất — đúng lúc nhiều quản trị viên dễ chủ quan vì nghĩ "chỉ là một lần nâng cấp định kỳ".
Bảng: Quy trình khôi phục switch kẹt ở ROMmon theo từng nguyên nhân
Nguyên nhân | Dấu hiệu | Bước khôi phục chính |
|---|---|---|
Thiếu/hỏng file | Switch rơi về ROMmon sau khi mất điện giữa lúc cập nhật | Kiểm tra |
Lỗi biến "Stack 1+1" | Thông báo "Active/standby selection failed in 1+1 Mode" | Gỡ biến bằng |
Hết dung lượng flash khi copy/upgrade | Lỗi trong quá trình nâng cấp, không hoàn tất | Kiểm tra dung lượng trống trên từng switch thành viên, xóa file không cần thiết hoặc format lại flash nếu hỏng, thử nâng cấp lại |
3. Vì sao đây là rủi ro đặc biệt đáng lưu ý cho switch core/aggregation
Với một switch access đơn lẻ phục vụ vài chục máy trạm, việc một switch kẹt ở ROMmon là sự cố nghiêm trọng nhưng khu trú. Với một core switch hoặc switch tổng trong stack phục vụ toàn bộ hạ tầng mạng của một tòa nhà/nhà máy — đúng vai trò mà Catalyst 9300 thường đảm nhiệm theo bằng chứng thị trường VN đã nêu ở bài trước (triển khai cùng cụm server ảo hóa ESXi) — một lần mất điện giữa lúc nâng cấp có thể khiến toàn bộ mạng doanh nghiệp ngừng hoạt động cho đến khi có kỹ sư mạng can thiệp thủ công qua console, vì ROMmon không thể tự phục hồi mà cần các bước thao tác tay (kết nối console, kiểm tra flash, chạy lệnh khôi phục) — không giống như một lần tắt/mở điện bình thường chỉ cần đợi switch tự khởi động lại.
4. Hệ quả khi StackPower không đủ ngân sách để chịu đựng việc mất hẳn một nguồn
Bài trước đã phân tích hành vi StackPower khi một nguồn chỉ bị "ảnh hưởng" (ví dụ do sụt áp). Với mất điện hoàn toàn — một nguồn trong stack mất điện vĩnh viễn (ví dụ do đứt nhánh điện riêng cấp cho switch đó, hoặc bộ nguồn hỏng hoàn toàn) — cơ chế xử lý về bản chất giống nhau nhưng tình huống nghiêm trọng hơn: không còn khả năng "nguồn đó phục hồi sau vài giây" như sụt áp, ngân sách công suất bị mất đi vĩnh viễn phần tương ứng với bộ nguồn đó cho đến khi được khôi phục vật lý.
Theo đúng tài liệu kỹ thuật đã trích ở bài trước, nếu ngân sách còn lại sau khi mất một nguồn không đủ, switch sẽ "bắt đầu quy trình tắt có trật tự theo mức ưu tiên đã cấu hình: cổng ưu tiên thấp bị cắt trước, sau đó đến cổng ưu tiên cao, cuối cùng mới đến toàn bộ switch". Điều quan trọng cần nhấn mạnh ở bài này: đây là một quy trình có chủ đích, không phải lỗi — hệ thống đang chủ động "hy sinh" các cổng ít quan trọng để giữ cho các cổng/switch quan trọng hơn tiếp tục hoạt động, miễn là quản trị viên đã cấu hình đúng mức ưu tiên từ trước. Nếu chưa cấu hình (tất cả ở mặc định "ưu tiên thấp" như đã nêu ở bài trước), việc cắt cổng sẽ diễn ra không theo thứ tự quan trọng thực tế mà quản trị viên mong muốn.
5. Quy trình tắt máy đúng cách trước khi mất điện có chủ đích (bảo trì, di chuyển thiết bị)
Khác với mất điện ngoài ý muốn, khi cần tắt switch có chủ đích (bảo trì, di chuyển rack, thay thế phần cứng), nên luôn dùng lệnh tắt/khởi động lại chính thức qua CLI (reload với xác nhận lưu cấu hình bằng write memory trước đó) thay vì rút điện trực tiếp — đảm bảo cấu hình đang chạy được lưu đầy đủ vào NVRAM trước khi mất điện, và switch không đang ở giữa bất kỳ quy trình ghi file nào (như nâng cấp firmware) tại thời điểm tắt.
6. Quy trình khôi phục sau khi có điện trở lại
Kiểm tra trạng thái boot của từng switch trong stack — xác nhận switch khởi động bình thường vào IOS XE, không kẹt ở ROMmon. Nếu thấy dấu hiệu ROMmon, tham khảo bảng khôi phục ở mục 2 trước khi thao tác thêm.
Kiểm tra log hệ thống (
show logging) và trạng thái StackPower (show stack-power) để xác nhận ngân sách công suất đã khôi phục đầy đủ, không còn ở trạng thái thiếu hụt từ sự cố trước.Xác nhận các cổng đã bị cắt theo mức ưu tiên (nếu có) đã được khôi phục lại bình thường sau khi nguồn đầy đủ trở lại — kiểm tra trạng thái từng cổng PoE/UPOE quan trọng.
Nếu sự cố xảy ra giữa lúc đang nâng cấp firmware, xác nhận lại phiên bản phần mềm thực tế đang chạy trên từng switch thành viên (
show version) — có thể quá trình nâng cấp chưa hoàn tất đồng bộ trên tất cả switch trong stack, cần hoàn tất lại quy trình nâng cấp một cách có kiểm soát.Ghi nhận sự cố vào hồ sơ vận hành hạ tầng mạng, bao gồm thời điểm mất điện, switch nào bị ảnh hưởng, và liệu có switch nào cần can thiệp thủ công qua console — làm cơ sở đánh giá nhu cầu nâng cấp giải pháp UPS nếu sự cố lặp lại.
7. Perpetual PoE và Fast PoE: hai tính năng giúp giảm thời gian gián đoạn cho thiết bị PoE sau khi có điện trở lại
Một điểm tích cực đáng nêu, giúp cân bằng lại hình ảnh rủi ro ở các mục trên: theo Data Sheet chính thức của Cisco, dòng Catalyst 9300 có hai tính năng liên quan trực tiếp đến hành vi cấp điện PoE khi switch khởi động lại — "Perpetual PoE" và "Fast PoE" (Cisco — Catalyst 9300 Series Switches Data Sheet).
Perpetual PoE đảm bảo "PoE power is maintained during a switch reload" (nguồn PoE được duy trì trong suốt quá trình switch reload) — nghĩa là khi switch khởi động lại có chủ đích (ví dụ sau khi hoàn tất nâng cấp firmware, dùng lệnh reload), các thiết bị PoE kết nối (camera an ninh, điện thoại IP, access point) không bị mất điện trong lúc switch tự khởi động lại phần mềm — dù bản thân switch tạm thời "không có trí tuệ" để chuyển mạch dữ liệu, nguồn điện vật lý cấp cho thiết bị đầu cuối vẫn được duy trì liên tục.
Fast PoE đảm bảo việc cấp điện PoE "begins without waiting for the operating system to fully load" (bắt đầu mà không cần chờ hệ điều hành tải xong hoàn toàn) — nghĩa là sau một lần mất điện hoàn toàn thật (khác với reload có chủ đích ở trên, nơi nguồn PoE chưa từng bị ngắt), khi điện lưới có trở lại và switch bắt đầu quy trình khởi động từ đầu, các cổng PoE có thể bắt đầu cấp điện cho thiết bị đầu cuối sớm hơn so với việc phải chờ toàn bộ hệ điều hành IOS XE khởi động xong và sẵn sàng chuyển mạch dữ liệu — rút ngắn đáng kể thời gian camera an ninh/điện thoại IP "có điện nhưng chưa có mạng" sau một lần mất điện thật.
Điểm cần lưu ý: hai tính năng này giải quyết đúng vấn đề thời gian có điện trở lại cho thiết bị đầu cuối, không giải quyết rủi ro ROMmon đã phân tích ở mục 2 — nếu switch kẹt ở ROMmon, không có hệ điều hành IOS XE nào khởi động để Fast PoE phát huy tác dụng, và toàn bộ lợi ích của hai tính năng này sẽ không xảy ra cho đến khi switch được khôi phục thủ công khỏi ROMmon.
8. Chi phí thực tế của việc không có UPS khi nâng cấp firmware định kỳ
Nâng cấp firmware là hoạt động bảo trì định kỳ, có thể lên kế hoạch trước — nghĩa là rủi ro mất điện giữa lúc nâng cấp hoàn toàn có thể giảm thiểu bằng một hành động đơn giản: đảm bảo UPS cấp nguồn ổn định cho switch trong suốt thời gian nâng cấp, không phụ thuộc vào điện lưới trong khung giờ nhạy cảm này. Chi phí của việc này gần như bằng không nếu đã có UPS sẵn — chỉ là một bước kiểm tra trước khi bắt đầu nâng cấp.
Ngược lại, chi phí của việc switch core kẹt ở ROMmon giữa giờ làm việc có thể rất lớn: toàn bộ mạng doanh nghiệp phía sau switch đó ngừng hoạt động, cần kỹ sư mạng có kỹ năng khắc phục ROMmon (không phải ai cũng quen thao tác console-level này) can thiệp trực tiếp tại chỗ — với doanh nghiệp không có kỹ sư mạng thường trực, thời gian chờ đơn vị tích hợp hệ thống tới xử lý có thể kéo dài nhiều giờ, trong khi toàn bộ hoạt động kinh doanh phụ thuộc vào mạng (giao dịch, email, hệ thống quản lý) bị đình trệ.
9. Checklist: giảm thiểu rủi ro mất điện hoàn toàn cho switch Cisco Catalyst 9300
Đã lắp UPS online đủ công suất cho tủ rack chứa switch core/stack chưa?
Đã đảm bảo UPS đủ thời gian lưu điện (runtime) để switch hoàn tất an toàn mọi quy trình nâng cấp firmware đang thực hiện chưa?
Đã luôn lên kế hoạch nâng cấp firmware vào thời điểm có UPS ổn định, tránh thực hiện khi nghi ngờ nguồn điện lưới không ổn định chưa?
Đã lưu cấu hình (
write memory) trước mỗi lần tắt/khởi động lại có chủ đích chưa?Đã cấu hình đúng mức ưu tiên cổng (port priority) cho StackPower theo tầm quan trọng thực tế của từng loại thiết bị kết nối chưa?
Đã có quy trình/người chịu trách nhiệm biết cách khôi phục switch từ ROMmon nếu sự cố xảy ra (console access, file image dự phòng trên USB/TFTP server) chưa?
Đã kiểm tra dung lượng flash còn trống trên từng switch thành viên trước mỗi lần nâng cấp, tránh lỗi hết dung lượng giữa quá trình chưa?
Đã ghi nhận đầy đủ lịch sử các lần mất điện/sự cố nguồn ảnh hưởng đến switch vào hồ sơ vận hành chưa?
10. Câu hỏi thường gặp (FAQ)
Mất điện bình thường (không phải lúc nâng cấp) có nguy hiểm như mất điện giữa lúc nâng cấp không? Không nguy hiểm bằng — nếu switch đang hoạt động bình thường (không ghi file, không nâng cấp), việc mất điện và khởi động lại thường diễn ra suôn sẻ qua đúng chu trình boot bình thường. Rủi ro ROMmon tập trung chủ yếu ở các thời điểm switch đang thực hiện thao tác ghi file nhạy cảm.
ROMmon có nguy hiểm đến mức mất toàn bộ cấu hình switch không? Không nhất thiết — cấu hình (startup-config) được lưu trong NVRAM, thường vẫn còn nguyên sau khi khôi phục switch khỏi ROMmon thành công, miễn là chính file NVRAM/flash không bị hỏng. Tuy nhiên quy trình khôi phục đòi hỏi thao tác console-level, không tự động.
Có cách nào để switch tự động thử khôi phục mà không cần can thiệp console không? Theo tài liệu đã tra cứu, các bước khôi phục ROMmon (boot bằng file cấu hình thay thế, gỡ biến lỗi, boot qua USB/TFTP) đều cần thao tác console thủ công — không có cơ chế tự động hoàn toàn được xác nhận trong tài liệu Cisco đã tham khảo.
Nếu không dùng StackPower (chỉ một switch đơn với 1-2 nguồn), còn cần lo về quy trình cắt cổng theo mức ưu tiên không? Với switch đơn có 2 nguồn dự phòng không tham gia StackPower, hành vi mất một nguồn thường đơn giản hơn — switch vẫn hoạt động bình thường bằng nguồn còn lại nếu nguồn đó đủ công suất cho toàn bộ switch, không có cơ chế cắt cổng theo ngân sách chia sẻ như trong một stack.
UPS cho switch cần runtime tối thiểu bao lâu để an toàn qua một lần nâng cấp firmware? Tài liệu Cisco đã tra cứu không nêu thời gian cụ thể cho một lần nâng cấp điển hình — thời gian này phụ thuộc số switch trong stack, kích thước package phần mềm, và tốc độ mạng/flash. Nên tham khảo release notes của phiên bản IOS XE cụ thể đang nâng cấp để ước tính thời gian, và đảm bảo UPS có runtime dư so với ước tính đó.
