Các giao diện lập trình

[dangquangminh]

Programmable Interfaces trong Network Automation: Khi CLI không còn là con đường duy nhất


Nhiều kỹ sư mạng bắt đầu sự nghiệp với CLI. Gõ lệnh, show output, copy-paste config. Trong nhiều năm, đó là cách vận hành mạng tiêu chuẩn.

Nhưng khi hạ tầng tăng lên hàng trăm hoặc hàng ngàn thiết bị, cloud-native architecture xuất hiện, telemetry real-time trở thành yêu cầu bắt buộc, thì CLI bắt đầu bộc lộ giới hạn.

Đây là lúc programmable interfaces bước vào cuộc chơi.

Hình trên mô tả khá rõ sự chuyển dịch từ mô hình quản trị mạng truyền thống sang model-driven programmability.

---

CLI chỉ là một interface, không phải toàn bộ hệ thống


Trên thiết bị Cisco IOS XE, chúng ta quen với:

• CLI
• SNMP
• WebUI

Đây đều là những cách để tương tác với thiết bị.

Nhưng Cisco bổ sung thêm một lớp interface hiện đại hơn:

• NETCONF
• RESTCONF
• gNMI

Điểm quan trọng:

Các giao diện này không thay thế hoàn toàn CLI, mà cung cấp additional methods để truy cập cùng một hệ thống dữ liệu cấu hình và operational state.

Hiểu đơn giản:

CLI là dành cho con người.

Programmable APIs là dành cho automation systems.

Ví dụ:

Con người:
show ip interface brief

Automation:
GET /restconf/data/ietf-interfaces:interfaces

Cùng mục tiêu.

Khác cách truy cập.

---

Vấn đề lớn của CLI trong automation


CLI hoạt động tốt cho tác vụ thủ công.

Nhưng automation thì khác.

CLI có nhiều hạn chế: 1. Output không có cấu trúc


CLI trả về text.

Ví dụ:
GigabitEthernet1 up up
GigabitEthernet2 administratively down

Automation script phải parse text.

Regex.
String matching.
Fragile logic.

Chỉ cần firmware upgrade làm thay đổi output formatting là script hỏng.

---

2. Không có schema chuẩn


CLI không định nghĩa rõ:

• field nào tồn tại
• kiểu dữ liệu là gì
• đâu là config
• đâu là operational state

Automation phải đoán.

---

3. Không transactional


Nếu push 50 dòng config:
conf t
interface gi1
description TEST
ip address ...
router ospf 1
...

Dòng 23 fail?

22 dòng trước vẫn đã apply.

Rollback thủ công.

---

4. Không phù hợp telemetry hiện đại


CLI polling:
show interface counters

không phải cách tốt để lấy metric liên tục mỗi giây.

---

YANG: trái tim của model-driven automation


Điểm cốt lõi trong slide:

YANG data models define the data

Đây là phần quan trọng nhất.

YANG không phải protocol.

YANG là data modeling language.

Nó mô tả:

• cấu trúc dữ liệu
• field
• kiểu dữ liệu
• hierarchy
• constraints
• config/state

Ví dụ logic:
interface
name
description
enabled
mtu

Automation không còn đoán nữa.

Thiết bị công bố schema rõ ràng.

---

Hai thế giới YANG phổ biến

OpenConfig


Vendor-neutral.

Được cộng đồng hỗ trợ:

• Google
• operators
• multi-vendor ecosystems

Ví dụ:
/openconfig-interfaces:interfaces

Ưu điểm:

portable automation.

Một script dùng cho nhiều vendor.

---

Cisco Native


Cisco-specific.

Expose đầy đủ feature Cisco.

Ví dụ:

• proprietary QoS
• platform-specific knobs
• advanced routing features

Tradeoff:

Powerful hơn nhưng lock-in cao hơn.

---

NETCONF: automation kiểu enterprise truyền thống


NETCONF dùng:

• XML
• SSH transport
• RPC model

Thiết kế cho network configuration management.

Ví dụ:

• get-config
• edit-config
• commit
• lock datastore

Điểm mạnh:

transactional configuration.

Ví dụ:
candidate config
validate
commit
rollback

Điều CLI rất khó làm sạch sẽ.

NETCONF phù hợp khi:

• enterprise automation
• configuration orchestration
• compliance enforcement

---

RESTCONF: thân thiện với DevOps


NETCONF mạnh.

Nhưng XML khá nặng.

RESTCONF sinh ra để hiện đại hơn.

REST principles:

• GET
• POST
• PUT
• PATCH
• DELETE

Transport:

HTTPS

Payload:

• JSON
• XML

Ví dụ:
GET https://router/restconf/data/ietf-interfaces:interfaces

Nếu team của bạn quen:

• Python requests
• Postman
• API testing
• web services

RESTCONF dễ tiếp cận hơn NETCONF.

---

gNMI: sinh ra cho telemetry tốc độ cao


Nếu NETCONF/RESTCONF thiên về config management…

gNMI thiên về:

• telemetry
• streaming data
• operational visibility

Nền tảng:

• gRPC
• protobuf
• subscription model

Thay vì polling:
show interface counters

ta subscribe:
/interface counters stream

Thiết bị push dữ liệu liên tục.

Điều này cực kỳ quan trọng cho:

• AIOps
• observability
• anomaly detection
• closed-loop automation

---

Vì sao SNMP dần yếu thế?


SNMP từng là vua monitoring.

Nhưng có nhiều hạn chế:

Polling model:
manager hỏi → device trả lời

Không efficient ở scale lớn.

Data model hạn chế.

MIB complexity.

Telemetry granularity thấp.

Streaming telemetry với gNMI giải quyết tốt hơn nhiều.

Điều này không có nghĩa SNMP chết.

Nó vẫn tồn tại.

Nhưng rõ ràng không còn là tương lai dài hạn.

---

Intent-Based Networking kết nối mọi thứ


Slide có nhắc:

Intent-based Network Infrastructure

Đây là tầng orchestration cao hơn.

Workflow:

Intent:

"toàn bộ access switch phải bật NTP"

Automation system:

• translate intent
• map vào YANG models
• push qua NETCONF/RESTCONF
• verify operational state
• remediate nếu drift

Đây là bước tiến từ:

manual configuration

→ automation scripts

→ intent-driven operations

---

Góc nhìn thực chiến


Nếu bạn là CCNA/CCNP:

Học RESTCONF trước.

Lý do:

• dễ hiểu
• JSON thân thiện
• Postman test nhanh
• Python automation đơn giản

Nếu bạn làm enterprise automation nghiêm túc:

NETCONF + YANG rất đáng đầu tư.

Nếu bạn làm observability/AIOps:

gNMI + streaming telemetry gần như bắt buộc.

---

Kết luận


CLI chưa chết. CLI sẽ còn sống rất lâu. Nhưng nếu automation strategy của bạn vẫn là:
send_command("show run")
parse with regex

thì bạn đang xây automation trên nền móng mong manh.

Tương lai của network automation nằm ở:

data models + APIs + telemetry-driven operations

Và đó chính là lý do programmable interfaces trở thành kiến thức bắt buộc với NetDevOps hiện đại.