Điểm giới hạn của việc quản lý định tuyến tĩnh
Sáu tháng trước, mạng lưới của chúng tôi đạt đến mức độ phức tạp mà việc cấu hình thủ công không còn đáp ứng được nữa. Chúng tôi đã mở rộng từ ba gateway đơn giản lên một hạ tầng đồ sộ gồm mười hai subnet trải dài trên các trung tâm dữ liệu tại Ashburn và Frankfurt. Bảng định tuyến của chúng tôi lúc đó là một tập hợp mong manh các bản ghi tĩnh. Mỗi khi chúng tôi cấp phát một VLAN mới hoặc một tunnel VPN site-to-site bị chập chờn, quản trị viên hệ thống lại phải cập nhật thủ công cho hàng loạt máy chủ.
Sự cố xảy ra vào một tối thứ Ba. Một lỗi đánh máy đơn giản trong lệnh ip route add đã gây ra tình trạng ngừng hoạt động suốt 40 phút cho toàn bộ môi trường staging. Một gateway duy nhất bắt đầu gây ra hiện tượng “black-holing” (mất gói tin) vì thiếu đường quay về cho một subnet mới tạo. Đây không chỉ là vấn đề lỗi con người. Đó là một bức tường cản trước khả năng mở rộng. Chúng tôi cần một mạng lưới có thể tự chữa lành mà không cần sự can thiệp trực tiếp của con người.
Vấn đề cốt lõi: Định tuyến tĩnh rất “thụ động”
Định tuyến tĩnh thất bại vì nó thiếu khả năng nhận biết trạng thái. Với kernel Linux, một route tĩnh là một chỉ dẫn mù quáng. Nếu interface mục tiêu ở trạng thái “UP”, kernel sẽ tiếp tục đẩy gói tin vào interface đó. Nó không quan tâm liệu router kế tiếp (next-hop) đã bị sập hay nhà cung cấp thượng nguồn đang gặp sự cố rò rỉ định tuyến (routing leak) nghiêm trọng. Gói tin đơn giản là biến mất vào hư không.
Để vận hành một hệ thống có khả năng phục hồi tốt, chúng tôi cần ba tính năng mà định tuyến tĩnh không thể cung cấp:
- Failover dưới một giây: Lưu lượng phải tự động chuyển hướng nếu một liên kết chính bị đứt.
- Tự động khám phá (Automated Discovery): Các subnet mới phải thông báo sự hiện diện của chúng cho toàn bộ hệ thống ngay lập tức.
- Giám sát sức khỏe: Các tuyến đường phải được thu hồi ngay khi đích đến không còn khả dụng.
Lựa chọn giải pháp phù hợp: Quagga vs. BIRD vs. FRR
Tôi đã dành một tuần để thử nghiệm ba ứng cử viên chính cho việc định tuyến trên Linux. Mỗi giải pháp đều có một thế mạnh riêng, nhưng chỉ có một cái phù hợp với nhu cầu production của chúng tôi.
1. Quagga
Quagga là “ông tổ” của định tuyến trên Linux, nhưng nó đã lộ rõ dấu hiệu tuổi tác. Việc phát triển đã bị đình trệ và nó gặp khó khăn với các khối lượng công việc đa luồng hiện đại. Trong quá trình thử nghiệm, nó mang lại cảm giác chậm chạp và thiếu hỗ trợ API mạnh mẽ mà chúng tôi mong muốn cho việc tự động hóa trong tương lai.
2. BIRD
BIRD là một “cỗ máy” thực sự. Nó là tiêu chuẩn công nghiệp cho các điểm trao đổi Internet (IXP) xử lý hàng triệu route. Tuy nhiên, cú pháp cấu hình của nó giống như một ngôn ngữ lập trình tùy biến. Trừ khi bạn có một kỹ sư mạng chuyên trách để quản lý các chính sách BGP, lộ trình học tập sẽ cực kỳ khó khăn đối với một đội ngũ DevOps thông thường.
3. FRRouting (FRR)
FRR là phiên bản fork hiện đại của Quagga, được hỗ trợ bởi các “ông lớn” như Nvidia và Broadcom. Nó sử dụng vtysh, một shell mô phỏng quy trình làm việc của Cisco IOS/Arista EOS. Với bất kỳ ai từng chạm vào switch phần cứng, nó sẽ tạo cảm giác rất quen thuộc. Nó xử lý OSPF, BGP và EVPN một cách dễ dàng, khiến nó trở thành lựa chọn linh hoạt nhất cho môi trường hybrid của chúng tôi.
Triển khai: OSPF và BGP trong môi trường Production
Sau 180 ngày vận hành thực tế, thiết lập của chúng tôi đã chứng minh được sự ổn định đáng kinh bàng. Chúng tôi sử dụng OSPF cho lưu lượng nội bộ (East-West) và BGP cho các kết nối bên ngoài (North-South). Cách tiếp cận giao thức kép này giúp cân bằng giữa tốc độ và khả năng kiểm soát chi tiết.
Bước 1: Cài đặt
Trên Ubuntu 22.04 hoặc 24.04, hãy bỏ qua các kho lưu trữ mặc định của hệ điều hành. Chúng thường lạc hậu so với các bản phát hành ổn định mới nhất. Thay vào đó, hãy sử dụng kho lưu trữ chính thức của FRR để đảm bảo bạn có các bản vá bảo mật mới nhất.
# Thêm kho lưu trữ chính thức
curl -s https://deb.frrouting.org/frr/keys.asc | sudo apt-key add -
FRRVER="frr-stable"
echo deb https://deb.frrouting.org/frr/ $(lsb_release -s -c) $FRRVER | sudo tee -a /etc/apt/sources.list.d/frr.list
sudo apt update && sudo apt install frr frr-pythontoolsTiếp theo, hãy kích hoạt các giao thức cụ thể bạn cần bằng cách chỉnh sửa /etc/frr/daemons. Trong thiết lập của chúng tôi, chúng tôi đặt bgpd=yes và ospfd=yes, sau đó khởi động lại dịch vụ.
Bước 2: Định tuyến nội bộ với OSPF
OSPF là công cụ “thiết lập một lần rồi quên” của chúng tôi cho các subnet nội bộ. Nó đảm bảo mọi gateway đều biết về các gateway còn lại. Hãy sử dụng vtysh để cấu hình thay vì chỉnh sửa trực tiếp các tệp văn bản thô.
sudo vtysh
conf t
router ospf
network 10.0.0.0/24 area 0
network 192.168.1.0/24 area 0
exit
wr memoryCấu hình này đã loại bỏ việc theo dõi thủ công của chúng tôi. Khi chúng tôi thêm một interface mới vào Area 0, tuyến đường sẽ lan truyền đến phần còn lại của cụm máy chủ trong vòng chưa đầy 200ms.
Bước 3: Kết nối bên ngoài qua BGP
BGP là yếu tố thiết yếu để kết nối với các nhà cung cấp đám mây như AWS hoặc Azure. Dưới đây là phiên bản rút gọn của cấu hình peer cho gateway AWS Direct Connect.
router bgp 65001
neighbor 169.254.0.1 remote-as 65002
neighbor 169.254.0.1 description AWS-Primary
!
address-family ipv4 unicast
network 10.50.0.0/16
exit-address-family
exitNhững bài học xương máu từ thực tế
Việc chuyển sang định tuyến động đã thay đổi toàn bộ triết lý vận hành của chúng tôi. Dưới đây là ba bài học quan trọng nhất từ sáu tháng qua.
1. Tầm nhìn là tất cả
Định tuyến động rất tuyệt vời cho đến khi một liên kết bắt đầu hiện tượng “flapping” (bật tắt liên tục). Điều này có thể kích hoạt một “cơn bão” tính toán lại tuyến đường. Hiện tại, chúng tôi xuất các chỉ số (metrics) của FRR sang Prometheus. Chúng tôi cần biết liệu một phiên BGP có bị ngắt hay không trong vòng vài giây, trước khi người dùng kịp báo cáo về tình trạng tăng độ trễ.
2. Tôn trọng quy trình làm việc với vtysh
Đừng cố gắng can thiệp thủ công vào /etc/frr/frr.conf. Sử dụng vtysh giúp kiểm tra cú pháp theo thời gian thực. Nó cho phép bạn áp dụng các thay đổi trực tiếp mà không làm gián đoạn luồng lưu lượng hiện có. Hãy làm quen với show ip route và show ip bgp summary; chúng là những công cụ chẩn đoán tốt nhất của bạn.
3. Đừng bao giờ tin tưởng hoàn toàn vào Neighbor
Luôn triển khai prefix list. Nếu bạn không lọc các neighbor BGP của mình, một peer cấu hình sai có thể vô tình gửi cho bạn một default route (0.0.0.0/0). Điều này sẽ chiếm quyền kiểm soát toàn bộ lưu lượng đi ra của bạn. Chúng tôi sử dụng các bộ lọc nghiêm ngặt để chỉ cho phép các subnet cụ thể và mong đợi.
ip prefix-list ONLY-OUR-SUBNETS permit 10.0.0.0/8 ge 24
!
route-map IMPORT-FILTER permit 10
match ip address prefix-list ONLY-OUR-SUBNETS
!Lời kết
Mạng lưới của chúng tôi hiện đã có khả năng phục hồi tốt hơn đáng kể. Trong một sự cố hỏng hóc phần cứng gần đây trên một edge gateway, FRR đã chuyển hướng lưu lượng sang đường dự phòng trong khoảng 2,4 giây. Không ai trong đội ngũ kỹ sư phải thức dậy lúc nửa đêm. Nếu bạn đang quản lý nhiều hơn một vài node Linux, hãy ngừng sử dụng định tuyến tĩnh. Thời gian thiết lập FRRouting sẽ xứng đáng ngay khi liên kết đầu tiên của bạn gặp sự cố mà người dùng không hề hay biết.
