Tweet
NETCONF, RESTCONF hay gNMI? Khi nào nên dùng cái nào trong thực chiến Network Automation?
Nếu bạn đang bước vào thế giới Network Automation / NetDevOps, sớm hay muộn bạn sẽ gặp câu hỏi này:
"Nên học NETCONF, RESTCONF hay gNMI?"
Thoạt nhìn, cả ba đều là API để nói chuyện với thiết bị mạng. Nhưng trong thực tế, chúng sinh ra cho những triết lý rất khác nhau.
Nhìn vào slide trên, ta thấy ba cột khá giống nhau:
Nhưng điểm khác biệt thực sự nằm ở kiến trúc, hiệu năng, khả năng mở rộng, và use case triển khai.
1. Khi nào dùng NETCONF?
NETCONF là "ông anh lớn" trong thế giới network programmability.
Ra đời để giải quyết bài toán:
Ví dụ:
show run | include ospf
Nếu vendor đổi format output, script của bạn chết.
NETCONF thay đổi cách tiếp cận.
Thay vì parse text CLI, bạn làm việc với structured data dựa trên YANG model.
NETCONF dùng RPC qua SSH.
Ví dụ operations:
Read:
<get>
<get-config>
Write:
<edit-config operation="create">
<edit-config operation="replace">
<edit-config operation="delete">
Subscription:
<establish-subscription>
Khi nào NETCONF phù hợp?
1. Enterprise automation
Nếu bạn quản lý:
NETCONF rất hợp.
Ví dụ:
2. Khi cần transaction consistency
NETCONF mạnh ở chỗ transaction model.
Ví dụ:
Điều này cực kỳ quan trọng.
CLI scripting:
config t
interface g1
ip address ...
router ospf ...
Nếu fail ở bước 3?
Thiết bị rơi vào trạng thái half-configured.
NETCONF xử lý tốt hơn nhiều.
3. Khi cần vendor-native model
Cisco IOS XE YANG model.
Juniper YANG model.
Arista YANG model.
Nếu automation bám vendor-specific features → NETCONF ổn.
Khi nào KHÔNG nên dùng NETCONF?
NETCONF không phải lựa chọn lý tưởng nếu: XML fatigue
Payload kiểu:
<rpc>
<edit-config>
<target>
<running/>
</target>
Automation engineer quen JSON sẽ thấy khá mệt.
High-frequency telemetry
NETCONF không sinh ra cho streaming scale lớn.
Nếu bạn muốn:
NETCONF không phải vua.
2. Khi nào dùng RESTCONF?
RESTCONF là nỗ lực đưa network automation gần hơn với web/API ecosystem.
Triết lý:
RESTCONF dùng HTTP verbs quen thuộc:
Read:
GET
Create:
POST
Update:
PUT
PATCH
Delete:
DELETE
Dữ liệu thường là:
JSON
hoặc XML.
Khi nào RESTCONF phù hợp?
1. Team DevOps / Developers
Nếu team quen:
RESTCONF dễ tiếp cận hơn NETCONF rất nhiều.
Ví dụ:
requests.get()
requests.patch()
Rất tự nhiên.
2. Integration nhanh
Ví dụ tích hợp với:
RESTCONF khá tiện.
3. CRUD automation
Các bài toán kiểu:
RESTCONF làm tốt.
Khi nào RESTCONF không lý tưởng?
Transaction model yếu hơn NETCONF
HTTP request mang tính stateless.
Không có cảm giác transaction mạnh như:
candidate
commit
rollback
Streaming telemetry không phải điểm mạnh
Polling:
GET
GET
GET
GET
ở scale lớn = đau khổ.
3. Khi nào dùng gNMI?
Đây là nơi câu chuyện đổi hoàn toàn.
gNMI không chỉ là API config.
Nó là API sinh ra cho cloud-scale networking.
Thế giới:
Core operations
Read:
GET
Update:
SET update
Replace:
SET replace
Delete:
SET delete
Streaming:
SUBSCRIBE
Khi nào gNMI phù hợp?
1. Streaming telemetry
Đây là killer feature.
Thay vì:
RESTCONF polling:
GET every 30 sec
gNMI:
subscribe once
stream continuously
Khác biệt cực lớn.
Ví dụ collect:
real-time.
2. Large-scale data center
Nếu môi trường:
gNMI sáng giá hơn.
3. Multi-vendor standardization
gNMI thường đi cùng:
OpenConfig
Thay vì vendor-specific madness.
Ví dụ cùng một model:
4. Event-driven automation
Ví dụ:
nếu interface down:
event -> automation trigger
Thay vì polling.
Khi nào KHÔNG nên dùng gNMI?
Learning curve cao hơn
Bạn sẽ gặp:
Ví dụ:
/interfaces/interface[name=Ethernet1]/state/counters
Không thân thiện với người mới.
Không phải mọi enterprise vendor đều mature như nhau
Support khác nhau giữa platforms.
Vendor matrix cần kiểm tra kỹ.
So sánh thực chiến
Chọn NETCONF nếu:
Bạn cần:
Điển hình:
Cisco campus / branch automation.
Chọn RESTCONF nếu:
Bạn cần:
Điển hình:
DevOps team tích hợp network vào pipeline.
Chọn gNMI nếu:
Bạn cần:
Điển hình:
modern DC / AI infra / service provider.
Góc nhìn thực tế
Nếu học Network Automation năm 2026:
NETCONF + RESTCONF = nền tảng bắt buộc.
Vì enterprise vẫn dùng nhiều.
gNMI = hướng tương lai.
Đặc biệt nếu bạn làm:
Một cách rất đơn giản:
NETCONF = transaction-heavy configuration API
RESTCONF = RESTful network API
gNMI = cloud-scale programmable network interface
Không có cái nào "best".
Chỉ có cái phù hợp với đúng bài toán.
Nếu bạn đang bước vào thế giới Network Automation / NetDevOps, sớm hay muộn bạn sẽ gặp câu hỏi này:
"Nên học NETCONF, RESTCONF hay gNMI?"
Thoạt nhìn, cả ba đều là API để nói chuyện với thiết bị mạng. Nhưng trong thực tế, chúng sinh ra cho những triết lý rất khác nhau.
Nhìn vào slide trên, ta thấy ba cột khá giống nhau:
- đều có khả năng đọc dữ liệu
- đều có khả năng cấu hình
- đều có thể xóa cấu hình
- một số hỗ trợ subscription / telemetry
Nhưng điểm khác biệt thực sự nằm ở kiến trúc, hiệu năng, khả năng mở rộng, và use case triển khai.
1. Khi nào dùng NETCONF?
NETCONF là "ông anh lớn" trong thế giới network programmability.
Ra đời để giải quyết bài toán:
SSH CLI scripting quá mong manh.
Ví dụ:
show run | include ospf
Nếu vendor đổi format output, script của bạn chết.
NETCONF thay đổi cách tiếp cận.
Thay vì parse text CLI, bạn làm việc với structured data dựa trên YANG model.
NETCONF dùng RPC qua SSH.
Ví dụ operations:
Read:
<get>
<get-config>
Write:
<edit-config operation="create">
<edit-config operation="replace">
<edit-config operation="delete">
Subscription:
<establish-subscription>
Khi nào NETCONF phù hợp?
1. Enterprise automation
Nếu bạn quản lý:
- Catalyst
- IOS XE
- NX-OS
- JunOS
- các thiết bị hỗ trợ NETCONF/YANG
NETCONF rất hợp.
Ví dụ:
- deploy VLAN
- push BGP config
- configure interfaces
- collect operational state
2. Khi cần transaction consistency
NETCONF mạnh ở chỗ transaction model.
Ví dụ:
- candidate config
- commit
- rollback
Điều này cực kỳ quan trọng.
CLI scripting:
config t
interface g1
ip address ...
router ospf ...
Nếu fail ở bước 3?
Thiết bị rơi vào trạng thái half-configured.
NETCONF xử lý tốt hơn nhiều.
3. Khi cần vendor-native model
Cisco IOS XE YANG model.
Juniper YANG model.
Arista YANG model.
Nếu automation bám vendor-specific features → NETCONF ổn.
Khi nào KHÔNG nên dùng NETCONF?
NETCONF không phải lựa chọn lý tưởng nếu: XML fatigue
Payload kiểu:
<rpc>
<edit-config>
<target>
<running/>
</target>
Automation engineer quen JSON sẽ thấy khá mệt.
High-frequency telemetry
NETCONF không sinh ra cho streaming scale lớn.
Nếu bạn muốn:
- thousands metrics/sec
- real-time telemetry
- hyperscale observability
NETCONF không phải vua.
2. Khi nào dùng RESTCONF?
RESTCONF là nỗ lực đưa network automation gần hơn với web/API ecosystem.
Triết lý:
"Tại sao network engineers phải học RPC XML kỳ quặc?"
RESTCONF dùng HTTP verbs quen thuộc:
Read:
GET
Create:
POST
Update:
PUT
PATCH
Delete:
DELETE
Dữ liệu thường là:
JSON
hoặc XML.
Khi nào RESTCONF phù hợp?
1. Team DevOps / Developers
Nếu team quen:
- REST API
- Postman
- curl
- Python requests
- JSON
RESTCONF dễ tiếp cận hơn NETCONF rất nhiều.
Ví dụ:
requests.get()
requests.patch()
Rất tự nhiên.
2. Integration nhanh
Ví dụ tích hợp với:
- ServiceNow
- custom portal
- internal orchestrator
- CI/CD pipeline
RESTCONF khá tiện.
3. CRUD automation
Các bài toán kiểu:
- create interface
- modify route
- delete VLAN
RESTCONF làm tốt.
Khi nào RESTCONF không lý tưởng?
Transaction model yếu hơn NETCONF
HTTP request mang tính stateless.
Không có cảm giác transaction mạnh như:
candidate
commit
rollback
Streaming telemetry không phải điểm mạnh
Polling:
GET
GET
GET
GET
ở scale lớn = đau khổ.
3. Khi nào dùng gNMI?
Đây là nơi câu chuyện đổi hoàn toàn.
gNMI không chỉ là API config.
Nó là API sinh ra cho cloud-scale networking.
Thế giới:
- hyperscaler
- data center fabric
- streaming telemetry
- OpenConfig
Core operations
Read:
GET
Update:
SET update
Replace:
SET replace
Delete:
SET delete
Streaming:
SUBSCRIBE
Khi nào gNMI phù hợp?
1. Streaming telemetry
Đây là killer feature.
Thay vì:
RESTCONF polling:
GET every 30 sec
gNMI:
subscribe once
stream continuously
Khác biệt cực lớn.
Ví dụ collect:
- interface counters
- BGP state
- CPU
- memory
- route churn
- drops
- latency
real-time.
2. Large-scale data center
Nếu môi trường:
- spine-leaf
- EVPN fabric
- cloud network
- AI infrastructure
- Kubernetes networking
gNMI sáng giá hơn.
3. Multi-vendor standardization
gNMI thường đi cùng:
OpenConfig
Thay vì vendor-specific madness.
Ví dụ cùng một model:
- Cisco
- Arista
- Juniper
4. Event-driven automation
Ví dụ:
nếu interface down:
event -> automation trigger
Thay vì polling.
Khi nào KHÔNG nên dùng gNMI?
Learning curve cao hơn
Bạn sẽ gặp:
- protobuf
- gRPC
- OpenConfig paths
Ví dụ:
/interfaces/interface[name=Ethernet1]/state/counters
Không thân thiện với người mới.
Không phải mọi enterprise vendor đều mature như nhau
Support khác nhau giữa platforms.
Vendor matrix cần kiểm tra kỹ.
So sánh thực chiến
Chọn NETCONF nếu:
Bạn cần:
- reliable config automation
- transaction safety
- vendor-native YANG
- enterprise automation
Điển hình:
Cisco campus / branch automation.
Chọn RESTCONF nếu:
Bạn cần:
- API đơn giản
- JSON
- web integration
- quick automation
Điển hình:
DevOps team tích hợp network vào pipeline.
Chọn gNMI nếu:
Bạn cần:
- hyperscale telemetry
- streaming data
- event-driven automation
- cloud/DC fabric observability
Điển hình:
modern DC / AI infra / service provider.
Góc nhìn thực tế
Nếu học Network Automation năm 2026:
NETCONF + RESTCONF = nền tảng bắt buộc.
Vì enterprise vẫn dùng nhiều.
gNMI = hướng tương lai.
Đặc biệt nếu bạn làm:
- AI infrastructure
- cloud networking
- observability
- intent-based automation
- closed-loop automation
Một cách rất đơn giản:
NETCONF = transaction-heavy configuration API
RESTCONF = RESTful network API
gNMI = cloud-scale programmable network interface
Không có cái nào "best".
Chỉ có cái phù hợp với đúng bài toán.
Attached Files