Ba năm trước tôi đang khởi động GNS3 để kiểm tra kịch bản BGP failover trước khi đẩy lên production. VM mất 8 phút để boot, ngốn 12 GB RAM, và crash hai lần trước khi tôi kịp ping giữa các router. Đó là lúc tôi bắt đầu tìm kiếm thứ gì đó tốt hơn — và Containerlab đã thay đổi tất cả.
Cả network engineer lẫn DevOps đều hiểu bài toán lab: bạn cần một môi trường thực tế để kiểm thử, nhưng dựng lên mất quá nhiều thời gian. Containerlab giải quyết điều này bằng cách định nghĩa và triển khai topology mạng đa nhà cung cấp dùng container thay vì VM cồng kềnh. Hỗ trợ đầy đủ giao thức định tuyến, image OS thực của các hãng, và toàn bộ lab khởi động trong vòng 60 giây.
Bắt Đầu Nhanh — Chạy Được Trong 5 Phút
Cài Containerlab thực sự rất nhanh. Bạn cần Docker đã được cài và một máy Linux (hoặc WSL2 trên Windows).
Cài Đặt Containerlab
# Cài bằng một lệnh duy nhất (script chính thức)
bash -c "$(curl -sL https://get.containerlab.dev)"
# Kiểm tra cài đặt
clab versionChỉ vậy thôi. Không pip, không virtualenv, không địa ngục dependency.
Lab Đầu Tiên — Ba Router, Hai Phút
Tạo file tên lab01.yml:
name: first-lab
topology:
nodes:
router1:
kind: linux
image: frrouting/frr:latest
router2:
kind: linux
image: frrouting/frr:latest
router3:
kind: linux
image: frrouting/frr:latest
links:
- endpoints: ["router1:eth1", "router2:eth1"]
- endpoints: ["router2:eth2", "router3:eth1"]Triển khai nó:
sudo clab deploy -t lab01.ymlBạn sẽ thấy các container khởi động và một bảng hiển thị IP quản lý của từng node. Tổng thời gian từ không có gì đến ba router kết nối với nhau: khoảng 25 giây trên laptop tầm trung.
Để kết nối vào router1:
sudo docker exec -it clab-first-lab-router1 vtyshKhi xong việc:
sudo clab destroy -t lab01.ymlContainer biến mất, network interface được dọn sạch, không để lại gì.
Đào Sâu Hơn — Hiểu Topology File của Containerlab
File YAML topology của Containerlab làm một việc: mô tả mạng của bạn. Khi đã hiểu cấu trúc, bạn có thể mô hình hóa hầu hết mọi kịch bản thực tế.
Các Loại Node và Image
Containerlab hỗ trợ sẵn nhiều loại node:
- linux — bất kỳ Docker image nào chạy Linux (FRRouting, Bird, VyOS)
- srl — Nokia SR Linux (miễn phí, đầy đủ tính năng, xuất sắc cho lab)
- ceos — Arista cEOS (cần đăng ký miễn phí tại arista.com)
- crpd — Juniper cRPD (cần license của Juniper)
- vr-ros — MikroTik RouterOS qua vrnetlab
Với hầu hết lab không có license nhà cung cấp, FRRouting trên Linux đã bao phủ OSPF, BGP, IS-IS, MPLS và nhiều hơn nữa. Nokia SR Linux miễn phí để kéo về và cho bạn trải nghiệm network OS thực sự.
Cấu Hình Node Lúc Triển Khai
Startup config được mount trực tiếp vào container qua key binds — không cần copy thủ công sau khi triển khai:
name: ospf-lab
topology:
nodes:
r1:
kind: linux
image: frrouting/frr:latest
binds:
- configs/r1/frr.conf:/etc/frr/frr.conf
- configs/r1/daemons:/etc/frr/daemons
r2:
kind: linux
image: frrouting/frr:latest
binds:
- configs/r2/frr.conf:/etc/frr/frr.conf
- configs/r2/daemons:/etc/frr/daemons
links:
- endpoints: ["r1:eth1", "r2:eth1"]
mtu: 9000Config router nằm trên máy host — quản lý được bằng version control, so sánh diff dễ dàng, và tái tạo được trên mọi máy.
Network Link và Các Thuộc Tính
Về bản chất link là các cặp veth. Đặt MTU, mô phỏng độ trễ, hoặc bridge sang interface vật lý của máy host — tất cả đều trong file topology:
links:
# Link đơn giản
- endpoints: ["r1:eth1", "r2:eth1"]
# Với mô phỏng suy giảm (mô phỏng độ trễ)
- endpoints: ["r1:eth2", "r3:eth1"]
mtu: 1500
# Bridge sang interface vật lý của máy host
- endpoints: ["r2:eth3", "host:ens4"]Nâng Cao — Lab BGP Đa Nhà Cung Cấp
Tôi dùng kiểu thiết lập này để kiểm tra thay đổi chính sách BGP trước khi động vào router production. Topology dưới đây chạy trong khoảng 45 giây trên máy 4 nhân với 8 GB RAM. GNS3 với VM Cisco IOS tương đương cần tối thiểu 16 GB.
Lab BGP với FRRouting
name: bgp-lab
topology:
nodes:
isp1:
kind: linux
image: frrouting/frr:latest
binds:
- configs/isp1/frr.conf:/etc/frr/frr.conf
- configs/isp1/daemons:/etc/frr/daemons
isp2:
kind: linux
image: frrouting/frr:latest
binds:
- configs/isp2/frr.conf:/etc/frr/frr.conf
- configs/isp2/daemons:/etc/frr/daemons
customer:
kind: linux
image: frrouting/frr:latest
binds:
- configs/customer/frr.conf:/etc/frr/frr.conf
- configs/customer/daemons:/etc/frr/daemons
client:
kind: linux
image: alpine:latest
links:
- endpoints: ["isp1:eth1", "customer:eth1"]
- endpoints: ["isp2:eth1", "customer:eth2"]
- endpoints: ["customer:eth3", "client:eth0"]Cấu hình BGP FRRouting tối giản cho router customer (configs/customer/frr.conf):
frr version 9.0
frr defaults traditional
hostname customer
router bgp 65001
bgp router-id 10.0.0.1
neighbor 10.0.1.1 remote-as 65010
neighbor 10.0.2.1 remote-as 65020
!
address-family ipv4 unicast
network 192.168.100.0/24
neighbor 10.0.1.1 soft-reconfiguration inbound
neighbor 10.0.2.1 soft-reconfiguration inbound
exit-address-family
!
line vty
!Và file daemons để bật BGP:
bgpd=yes
ospfd=no
zebra=yes
vtysh_enable=yesKiểm Tra Lab Đang Chạy
# Hiển thị tất cả node và IP quản lý của chúng
sudo clab inspect -t bgp-lab.yml
# Kết nối vào vtysh của router customer
sudo docker exec -it clab-bgp-lab-customer vtysh
# Bên trong vtysh — kiểm tra BGP neighbor
show bgp summary
show ip route bgp
# Bắt gói tin trên eth1
sudo ip netns exec clab-bgp-lab-customer tcpdump -i eth1 -nDùng Nokia SR Linux (Miễn Phí, Không Cần License)
name: srl-lab
topology:
nodes:
leaf1:
kind: srl
image: ghcr.io/nokia/srlinux:latest
leaf2:
kind: srl
image: ghcr.io/nokia/srlinux:latest
spine1:
kind: srl
image: ghcr.io/nokia/srlinux:latest
links:
- endpoints: ["leaf1:e1-1", "spine1:e1-1"]
- endpoints: ["leaf2:e1-1", "spine1:e1-2"]SR Linux đi kèm CLI đầy đủ cùng các interface gRPC, gNMI và JSON-RPC — rất tốt để kiểm thử script tự động hóa với thứ gì đó hoạt động thực sự như OS của nhà cung cấp thật.
Mẹo Thực Chiến Từ Kinh Nghiệm
So Sánh Tài Nguyên: Containerlab vs GNS3
Trên cùng một máy 8 nhân, 16 GB RAM, chạy topology OSPF 5 node:
- GNS3 với VM Cisco IOS: ~10 GB RAM, boot mất 4-8 phút, một VM mỗi router
- Containerlab với FRRouting: ~400 MB RAM, dưới 30 giây, một container mỗi router
- Containerlab với Nokia SR Linux: ~1.2 GB RAM mỗi node, 60-90 giây, OS vendor đầy đủ
Với hầu hết bài kiểm thử giao thức — OSPF, BGP, MPLS, chính sách định tuyến — container FRRouting cho bạn tất cả những gì cần với một phần nhỏ chi phí tài nguyên.
Lưu và Khôi Phục Cấu Hình Router
Sau khi thay đổi thủ công trong vtysh, lưu config trở lại máy host:
# Lưu running config từ container về máy host
sudo docker exec clab-bgp-lab-customer vtysh -c "write memory"
sudo docker cp clab-bgp-lab-customer:/etc/frr/frr.conf ./configs/customer/frr.confGiờ config lab của bạn được quản lý bằng version control. Push lên Git, chia sẻ với đồng nghiệp, tái tạo lab y hệt ở bất kỳ đâu.
Tích Hợp Containerlab vào CI/CD
Mô hình file YAML kết hợp Docker image phù hợp tự nhiên với CI pipeline. Kiểm tra thay đổi cấu hình mạng trước khi merge:
# .github/workflows/network-test.yml
jobs:
network-lab-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Cài Containerlab
run: bash -c "$(curl -sL https://get.containerlab.dev)"
- name: Triển khai lab
run: sudo clab deploy -t tests/bgp-lab.yml
- name: Chạy kiểm tra kết nối
run: |
sleep 30 # Chờ BGP hội tụ
sudo docker exec clab-bgp-lab-client ping -c 3 192.168.100.1
- name: Xóa lab
if: always()
run: sudo clab destroy -t tests/bgp-lab.ymlVẽ Sơ Đồ Topology
Còn có một công cụ trực quan hóa topology tích hợp sẵn:
sudo clab graph -t bgp-lab.ymlLệnh này mở trình duyệt web với sơ đồ topology tương tác — hữu ích cho tài liệu hóa và nắm bắt nhanh các lab phức tạp.
Các Lệnh clab Hữu Ích Cần Nhớ
# Liệt kê tất cả lab đang chạy
sudo clab inspect --all
# Triển khai lại mà không xóa (cấu hình lại)
sudo clab redeploy -t lab01.yml
# Triển khai với prefix riêng để tránh xung đột tên
sudo clab deploy -t lab01.yml --prefix myproject
# Lưu tất cả cấu hình node cùng lúc
sudo clab save -t lab01.ymlNếu bạn làm network engineering nghiêm túc hoặc tự động hóa hạ tầng, thành thạo Containerlab sẽ mang lại lợi ích rất nhanh. Dựng lên, kiểm thử, phá, và xây lại — tất cả trong dưới một phút, không cần lab vật lý, không tốn phí hypervisor VM. Khi topology YAML và config router cùng nằm trong một Git repo, khoảng cách giữa “kiểm thử trên lab” và “tự tin lên production” gần như thu về bằng không.
Hãy bắt đầu với thiết lập hai router FRRouting. Làm quen với cú pháp YAML, rồi chuyển sang SR Linux hoặc cEOS khi cần hành vi đặc thù của từng nhà cung cấp. Một buổi chiều là đủ để bạn làm việc hiệu quả với công cụ này.
