Vietnamese Professional - Thiết bị mạng - Unix - Microsoft https://www.forum.vnpro.org/ Juniper, Huawei, Alcatel, Lucent,Checkpoint, ... vi Sun, 07 Jun 2026 14:26:41 GMT vBulletin 60 images/misc/rss.png Vietnamese Professional - Thiết bị mạng - Unix - Microsoft https://www.forum.vnpro.org/ Monitoring và Operations đang thay đổi như thế nào trong thời đại Network Automation? https://www.forum.vnpro.org/forum/giải-pháp-mạng/thiết-bị-mạng/440985-monitoring-và-operations-đang-thay-đổi-như-thế-nào-trong-thời-đại-network-automation Tue, 02 Jun 2026 07:15:24 GMT Monitoring và Operations đang thay đổi như thế nào trong thời đại Network Automation? Nếu nhìn vào bức tranh vận hành hạ tầng CNTT trong khoảng... Monitoring và Operations đang thay đổi như thế nào trong thời đại Network Automation?


Nếu nhìn vào bức tranh vận hành hạ tầng CNTT trong khoảng 20 năm qua, chúng ta sẽ thấy một sự chuyển dịch rất rõ ràng: từ CLI và SNMP sang các giao diện lập trình hiện đại dựa trên mô hình dữ liệu (Model-Driven Programmability).

Biểu đồ trên so sánh các công nghệ phổ biến đang được sử dụng để giám sát và vận hành hệ thống mạng.

CLI vẫn là công cụ quen thuộc nhất với kỹ sư mạng. Nó cho phép cấu hình và provisioning trực tiếp trên thiết bị nhưng khó mở rộng khi số lượng thiết bị tăng lên hàng trăm hoặc hàng nghìn node. Tương lai của CLI vẫn tồn tại nhưng chủ yếu phục vụ troubleshooting và các tác vụ thủ công.

SNMP từng là "vua của monitoring" trong nhiều năm. Hầu hết các hệ thống NMS truyền thống đều dựa trên SNMP Polling. Tuy nhiên SNMP gần như chỉ phù hợp cho việc đọc trạng thái thiết bị, khả năng cấu hình rất hạn chế và khó đáp ứng nhu cầu telemetry thời gian thực của hạ tầng hiện đại.

NETCONF/YANG và RESTCONF đánh dấu bước chuyển sang kiến trúc Model-Driven. Thay vì gửi từng lệnh CLI, kỹ sư có thể làm việc trực tiếp với các mô hình dữ liệu chuẩn. Đây là nền tảng quan trọng cho Infrastructure as Code (IaC), Network Automation, CI/CD và GitOps trong môi trường mạng.

gRPC Streaming Telemetry xuất hiện để giải quyết hạn chế của SNMP Polling. Thay vì liên tục hỏi thiết bị "có gì mới không?", thiết bị chủ động đẩy dữ liệu về collector theo thời gian thực. Điều này giúp giảm tải CPU, giảm lưu lượng polling và cung cấp khả năng quan sát hệ thống tốt hơn rất nhiều.

gNMI (gRPC Network Management Interface) được xem là một trong những giao thức quản lý mạng có tiềm năng lớn nhất hiện nay. Nó kết hợp sức mạnh của YANG Data Model với nền tảng truyền tải gRPC hiệu năng cao, hỗ trợ cả cấu hình, truy vấn trạng thái và streaming telemetry trong cùng một framework.

Điểm thú vị là độ trưởng thành (Maturity) của SNMP hiện nay vẫn rất cao vì đã tồn tại hàng chục năm, nhưng tương lai lại khá hạn chế. Ngược lại, gNMI và Streaming Telemetry có độ trưởng thành thấp hơn nhưng đang phát triển rất nhanh và được các nhà cung cấp lớn như Cisco, Arista, Juniper, Nokia và NVIDIA đầu tư mạnh.

Đối với kỹ sư Network Automation và NetDevOps, lộ trình học tập hợp lý hiện nay thường là:

CLI → API → YANG → NETCONF/RESTCONF → gRPC Telemetry → gNMI

Đây cũng chính là hướng phát triển của các nền tảng vận hành hiện đại, nơi dữ liệu được thu thập theo thời gian thực, tự động hóa được triển khai bằng code và toàn bộ hạ tầng có thể được quản lý giống như một hệ thống phần mềm. #NetDevOps #NetworkAutomation devops #gNMI #gRPC yang netconf restconf #InfrastructureAsCode #Telemetry
​]]> Thiết bị mạng - Unix - Microsoft dangquangminh https://www.forum.vnpro.org/forum/giải-pháp-mạng/thiết-bị-mạng/440985-monitoring-và-operations-đang-thay-đổi-như-thế-nào-trong-thời-đại-network-automation Xây dựng custom dashboard https://www.forum.vnpro.org/forum/giải-pháp-mạng/thiết-bị-mạng/440874-xây-dựng-custom-dashboard Fri, 29 May 2026 13:11:14 GMT Tại sao DevOps Engineer nên biết cách xây dựng Custom Dashboard? Một trong những kỹ năng rất giá trị của DevOps, NetDevOps và Automation... Tại sao DevOps Engineer nên biết cách xây dựng Custom Dashboard?


Một trong những kỹ năng rất giá trị của DevOps, NetDevOps và Automation Engineer hiện nay không phải là tạo thêm dashboard đẹp mắt, mà là khả năng kết hợp dữ liệu từ nhiều hệ thống khác nhau để tạo ra một "Single Pane of Glass" phục vụ vận hành.

Hãy lấy ví dụ Cisco DNA Center. Mặc dù Cisco đã cung cấp sẵn dashboard mặc định, nhưng trong thực tế doanh nghiệp thường có nhu cầu rất khác nhau. Đội vận hành mạng có thể chỉ cần trạng thái thiết bị. Help Desk cần nhìn thấy số lượng sự cố đang xảy ra. Ban quản lý muốn theo dõi KPI tổng hợp từ nhiều hệ thống khác nhau. Một dashboard duy nhất khó có thể đáp ứng tất cả các nhu cầu đó.

Đây là lúc API phát huy sức mạnh.

Khi các hệ thống back-end hỗ trợ REST API, chúng ta có thể xây dựng một giao diện tùy chỉnh để thu thập và hiển thị dữ liệu theo đúng nhu cầu của tổ chức. Cisco DNA Center là một ví dụ điển hình. Dashboard mặc định thực chất chỉ là một front-end giao tiếp với back-end thông qua Intent API.

Quy trình hoạt động khá đơn giản:
  • Gửi yêu cầu POST tới API /auth/token
  • Truyền username và password
  • Nhận về authentication token
  • Sử dụng token trong header X-Auth-Token
  • Thực hiện các API GET, POST, PUT hoặc DELETE tiếp theo

Ví dụ, để lấy thông tin Site Health, ứng dụng chỉ cần gửi yêu cầu GET tới API tương ứng. Kết quả trả về có thể bao gồm:
  • Tên site
  • Số lượng thiết bị hoạt động tốt
  • Số lượng thiết bị gặp lỗi
  • Tổng số thiết bị
  • Các chỉ số vận hành khác

Sau đó dữ liệu được trình bày theo cách phù hợp với từng nhóm người dùng.

Điểm thú vị là kiến trúc ứng dụng hiện đại thường được xây dựng theo mô hình phân tán (Distributed Application). Front-end và Back-end tách biệt hoàn toàn với nhau. Điều này cho phép:
  • Một back-end phục vụ nhiều giao diện khác nhau (Web, Mobile, Desktop)
  • Một dashboard có thể tổng hợp dữ liệu từ nhiều hệ thống khác nhau
  • Thay đổi giao diện mà không ảnh hưởng tới logic xử lý phía sau

Các công nghệ front-end phổ biến gồm HTML, CSS, JavaScript, React, Angular hoặc .NET. Trong khi đó back-end thường được xây dựng bằng Python, Java, PHP, Ruby hoặc .NET.

Đối với dân Automation, Python là lựa chọn rất phổ biến. Chỉ với thư viện requests, chúng ta có thể xác thực API, lấy dữ liệu từ Cisco DNA Center, ServiceNow, GitLab, Prometheus, Grafana hoặc bất kỳ hệ thống nào hỗ trợ REST API.

Đây cũng chính là nền tảng của rất nhiều hệ thống AIOps, NOC Dashboard và Automation Portal hiện đại.

Điều quan trọng nhất không phải là viết code, mà là trả lời được câu hỏi:

Bạn đang cố giải quyết vấn đề gì cho doanh nghiệp?

Khi xác định được nhu cầu vận hành, API sẽ giúp bạn biến dữ liệu từ nhiều hệ thống khác nhau thành một dashboard duy nhất, đơn giản hóa vận hành và nâng cao hiệu quả tự động hóa.
​]]> Thiết bị mạng - Unix - Microsoft dangquangminh https://www.forum.vnpro.org/forum/giải-pháp-mạng/thiết-bị-mạng/440874-xây-dựng-custom-dashboard eBPF https://www.forum.vnpro.org/forum/giải-pháp-mạng/thiết-bị-mạng/440642-ebpf Mon, 25 May 2026 01:21:28 GMT eBPF là gì? Vì sao dân DevOps / Cloud Native / Security đang nói rất nhiều về nó? Nếu Kubernetes thay đổi cách chúng ta triển khai ứng dụng, thì... eBPF là gì? Vì sao dân DevOps / Cloud Native / Security đang nói rất nhiều về nó?


Nếu Kubernetes thay đổi cách chúng ta triển khai ứng dụng, thì eBPF đang thay đổi cách chúng ta tương tác với nhân Linux kernel.
eBPF (extended Berkeley Packet Filter) là công nghệ cho phép chạy các chương trình tùy chỉnh trực tiếp bên trong Linux kernel một cách an toàn. Điều này biến kernel từ một thành phần “đóng” thành một nền tảng có thể lập trình được. Thay vì phải sửa mã nguồn kernel, biên dịch lại, reboot server hoặc viết kernel module phức tạp, eBPF cho phép nạp logic động vào kernel khi hệ thống đang chạy.
Sau đây là một mô tả cụ thể. Application của bạn chạy ở userspace. Thông thường, khi app cần truy cập file, network socket, memory, process information... nó phải đi qua system calls để nói chuyện với kernel. Với eBPF, bạn có thể “gắn” chương trình nhỏ vào các sự kiện trong kernel như một packet đi vào network stack, hoặc system call được gọi, process được tạo, file được truy cập, TCP connection được mở, security event xảy ra....eBF giúp tất cả các tác vụ này nói chuyện với nhân linux kernel dễ dàng hơn.
Khi event xảy ra, chương trình eBPF chạy ngay bên trong kernel.
Điều này tạo ra hiệu năng cực cao vì chúng ta không cần context switching liên tục giữa userspace và kernel. Nó cũng giúp giảm overhead, lý do là vì xử lý gần nguồn dữ liệu nhất. Khà năng giám sát cũng gần với thời gian thực. Vì sao eBPF đặc biệt quan trọng với Kubernetes?


Trong môi trường Kubernetes, application chạy trong containers, containers lại nằm trong Pods. Pods thì phân bố trên nhiều Nodes, mỗi Node có một Linux kernel. Điểm quan trọng Kernel nhìn thấy toàn bộ những gì đang xảy ra trên host. Kernel lúc này biết container nào đang chạy, process nào tạo kết nối, packet nào đi đâu hay pod nào nói chuyện với pod nào, ai truy cập file nào, syscall nào đang được gọi....và nhiều thức khác.
Đây là lý do eBPF trở thành “vũ khí mới” trong cloud-native. 3 ỨNG DỤNG lớn của eBPF

1. Networking


eBPF có thể can thiệp trực tiếp vào packet path. Ví dụ như load balancing, routing, packet filtering, NAT, service mesh acceleration, replacing iptables bottlenecks
Một ví dụ nổi tiếng là sản phẩm Cilium. Cilium dùng eBPF để thay thế nhiều phần networking truyền thống trong Kubernetes. Thay vì phụ thuộc nặng vào iptables, Cilium đưa packet processing xuống kernel-level. Cách này giúp cho độ trễ thấp hơn, thru put cao hơn.

2. Observability


eBPF rất mạnh trong monitoring. Bạn có thể theo dõi syscalls, TCP latency, DNS queries, file access, process behavior, container activity...mà không cần các intrusive agents nặng nề. Ví dụ Pixie, bpftrac, BCC, Parca. Đây là lý do eBPF đang thay đổi cách observability hoạt động.

3. Security


Security team cực kỳ thích eBPF vì tính khả kiến visibility rất sâu. Có thể giúp chúng ta phát hiện suspicious process execution, privilege escalation, malware behavior....Ví dụ tools Falco (eBPF mode), Tetragon, Tracee. Thay vì chỉ nhìn logs sau khi sự cố xảy ra, eBPF giúp quan sát hành vi runtime.

Một cách nhìn dễ nhớ


Nếu Docker là “virtualization nhẹ”. Thì eBPF là programmable infrastructure inside Linux kernel. Hoặc dễ hình dung hơn iptables + tcpdump + strace + observability agent + security sensor ... nhưng hiện đại hơn, nhanh hơn, kernel-native hơn. eBPF đang là nền tảng phía sau rất nhiều công nghệ cloud-native hiện đại Kubernetes networking, runtime security, observability, zero-trust workload security, service mesh evolution. Nếu bạn đang làm DevOps, Platform Engineering, Kubernetes, Cloud Security, SRE, AI Infrastructure thì eBPF là chủ đề đáng đọc thêm.​]]> Thiết bị mạng - Unix - Microsoft dangquangminh https://www.forum.vnpro.org/forum/giải-pháp-mạng/thiết-bị-mạng/440642-ebpf Vsan https://www.forum.vnpro.org/forum/giải-pháp-mạng/thiết-bị-mạng/440385-vsan Tue, 19 May 2026 03:08:00 GMT VSAN trong Storage Networking là gì? Khi SAN cũng cần “virtualization” giống Ethernet Nếu anh em network đã quen với VLAN trong Ethernet hay VRF... VSAN trong Storage Networking là gì? Khi SAN cũng cần “virtualization” giống Ethernet

Nếu anh em network đã quen với VLAN trong Ethernet hay VRF trong Layer 3 routing, thì trong thế giới Storage Area Network (SAN) cũng có một khái niệm tương tự: VSAN (Virtual SAN).

Cisco giới thiệu VSAN từ năm 2002 để giải quyết một vấn đề rất thực tế trong môi trường Fibre Channel SAN: làm sao chia nhỏ một hạ tầng SAN vật lý lớn thành nhiều fabric logic độc lập, mà không phải mua nhiều bộ switch riêng biệt.
Vấn đề của SAN truyền thống


Thời kỳ đầu, khi triển khai SAN, cách phổ biến là xây dựng các SAN island.

Ví dụ:
  • Một nhóm server dùng một SAN fabric riêng
  • Nhóm database dùng SAN riêng
  • Storage team dựng thêm SAN riêng cho backup
  • Một ứng dụng mission-critical lại cần SAN riêng để cách ly

Nghe có vẻ hợp lý.

Nhưng hậu quả là:
  • Rất nhiều switch Fibre Channel
  • Port bị lãng phí
  • Chi phí CAPEX cao
  • Quản lý phức tạp
  • Troubleshooting đau đầu

Đây chính là lý do VSAN xuất hiện.
VSAN là gì?


VSAN (Virtual Storage Area Network) là cơ chế chia một physical Fibre Channel fabric thành nhiều logical fabric độc lập.

Mỗi VSAN hoạt động như một SAN riêng biệt, mặc dù tất cả cùng chạy trên cùng một hạ tầng switch vật lý.

Hãy hình dung:
  • VLAN → chia Layer 2 Ethernet thành nhiều broadcast domain
  • VRF → chia router thành nhiều routing table
  • VSAN → chia SAN fabric thành nhiều storage fabric logic

Đây chính là virtualization trong storage networking.
Cách hoạt động


Mỗi cổng Fibre Channel trên switch có thể được gán vào một VSAN cụ thể.

Ví dụ:
vsan 2 interface fc1/1
vsan 2 interface fc1/2
vsan 43 interface fc1/8
vsan 43 interface fc1/9

Điều này nghĩa là:
  • fc1/1 và fc1/2 thuộc VSAN 2
  • fc1/8 và fc1/9 thuộc VSAN 43

Hai VSAN này không “nhìn thấy nhau” trừ khi có cấu hình inter-VSAN routing.
Điều gì được cô lập?


Điểm mạnh nhất của VSAN là isolation.

Không chỉ traffic được tách biệt.

Mà cả control plane cũng được chia riêng.

Bao gồm:
  • Name Server
  • Zone Server
  • Login Server
  • Fabric Services
  • Routing state
  • Event notification

Ví dụ:

RSCN (Registered State Change Notification) chỉ phát trong VSAN tương ứng.

Nếu VSAN 43 có thiết bị flap:
  • VSAN 43 bị ảnh hưởng
  • VSAN khác hoàn toàn bình thường

Đây là lợi ích cực lớn cho High Availability.
Hardware enforced isolation


Đây không chỉ là logical tagging kiểu mềm.

Cisco implement isolation ở mức hardware.

Điều đó mang lại:
  • hiệu năng tốt
  • predictability
  • ít nguy cơ leakage giữa fabric

Khá giống cách TCAM enforce policy trong switching.
FC routing riêng cho từng VSAN


Mỗi VSAN có topology riêng.

Ví dụ:
show fspf vsan 43

Output sẽ cho thấy:
  • FSPF routing status
  • autonomous region
  • link-state info
  • checksum

Điều này cho thấy mỗi VSAN có control plane riêng.

Không phải chỉ đơn giản là chia traffic.
Zoning riêng từng VSAN


Ví dụ:
show zoneset active vsan 43

Output:
zoneset name UCS-Fabric-B vsan 43
zone name UCS-B-VMware-Netapp vsan 43

Điều này nghĩa là zoning policy được tách riêng hoàn toàn.

Storage admin có thể quản lý từng fabric độc lập.
Lợi ích thực tế

1. Tối ưu port utilization


Thay vì:
  • 3 SAN riêng
  • mỗi SAN vài switch
  • port dư thừa

Ta gom thành một physical fabric lớn.

Sau đó chia logic bằng VSAN.

Hiệu quả kinh tế cao hơn nhiều.
2. Fault isolation


Một fabric lỗi không kéo sập toàn hệ thống.

Ví dụ:
  • zoning lỗi
  • device flap
  • fabric reconfiguration storm

Chỉ impact VSAN tương ứng.
3. Quản trị đơn giản hơn


Ít switch hơn.

Ít dây hơn.

Ít thiết bị hơn.

Nhưng vẫn giữ isolation.
4. High Availability tốt hơn


Control plane event được giới hạn trong từng VSAN.

Giảm blast radius.
5. Multi-tenant support


Rất phù hợp khi:
  • shared data center
  • enterprise nhiều business unit
  • service provider storage
So sánh nhanh với network world


Nếu nhìn từ góc network engineer:
  • VLAN = chia Ethernet domain
  • VRF = chia routing domain
  • VSAN = chia storage fabric

Tư duy hoàn toàn giống nhau.
Có phải VSAN giống VMware vSAN?


Không.

Đây là điểm nhiều người nhầm.

Cisco VSAN:
  • Fibre Channel SAN virtualization
  • network/storage fabric segmentation

VMware vSAN:
  • software-defined storage
  • hyperconverged storage platform

Hai khái niệm hoàn toàn khác nhau.

Chỉ trùng chữ “vSAN”.
Góc nhìn thực chiến


Trong data center enterprise lớn, đặc biệt với:
  • UCS
  • NetApp
  • EMC
  • IBM storage
  • Fibre Channel SAN

VSAN là một design pattern gần như tiêu chuẩn.

Lý do:

physical consolidation + logical isolation.

Đây chính là một trong những ví dụ rất sớm của infrastructure virtualization—thậm chí xuất hiện trước khi cloud trở thành xu hướng chính.

Kết luận

VSAN mang triết lý rất quen thuộc với network engineer:
Đừng xây nhiều hạ tầng vật lý nếu có thể chia logic một cách an toàn.

Ethernet có VLAN.

Routing có VRF.

Storage có VSAN.

Cùng một tư duy. Khác battlefield.
​]]> Thiết bị mạng - Unix - Microsoft dangquangminh https://www.forum.vnpro.org/forum/giải-pháp-mạng/thiết-bị-mạng/440385-vsan Syslog Troubleshooting https://www.forum.vnpro.org/forum/giải-pháp-mạng/thiết-bị-mạng/440164-syslog-troubleshooting Tue, 12 May 2026 11:29:23 GMT Bí quyết Troubleshooting Syslog trên Cisco IOS, Windows và Linux Syslog là một trong những công cụ quan trọng nhất trong vận hành hệ thống và... Bí quyết Troubleshooting Syslog trên Cisco IOS, Windows và Linux


Syslog là một trong những công cụ quan trọng nhất trong vận hành hệ thống và mạng. Khi mọi thứ hoạt động bình thường, syslog chỉ đơn giản là nơi ghi nhận sự kiện. Nhưng khi sự cố xảy ra, syslog lại trở thành “hộp đen” giúp kỹ sư lần ngược nguyên nhân.

Thực tế, rất nhiều tình huống troubleshooting kéo dài không phải vì lỗi quá phức tạp, mà vì log không đến nơi, log bị thiếu, timestamp sai, hoặc mức severity cấu hình không đúng.

Bài này sẽ hướng dẫn cách troubleshooting syslog theo tư duy thực chiến trên ba nền tảng phổ biến: Cisco IOS, Windows Server và Linux.
Bước 1: Luôn kiểm tra câu hỏi cơ bản nhất — Syslog có thực sự đang chạy không?


Nghe có vẻ hiển nhiên, nhưng đây là lỗi phổ biến nhất.

Rất nhiều kỹ sư lao ngay vào phân tích firewall, routing hay application, trong khi thực tế logging chưa được bật.
Troubleshooting Syslog trên Cisco IOS

Kiểm tra trạng thái logging


Lệnh đầu tiên:
show logging

Ví dụ output:
R1# show logging
Syslog logging: enabled
Console logging: level informational
Monitor logging: level informational
Buffer logging: level debugging
Trap logging: level warnings
Logging to 10.1.100.100 (udp port 514)

Điều cần đọc trong output này:

Syslog logging: enabled

Nếu thấy disabled thì syslog chưa chạy.
Kiểm tra severity level


Đây là lỗi số 1 khi “không thấy log”.

Cisco syslog dùng severity từ 0 đến 7:
  • 0 Emergency
  • 1 Alert
  • 2 Critical
  • 3 Error
  • 4 Warning
  • 5 Notification
  • 6 Informational
  • 7 Debugging

Ví dụ:
logging trap warnings

Điều này có nghĩa chỉ gửi log mức 0–4 lên syslog server.

Nếu bạn đang debug routing:
debug ip ospf events

thì log debug severity 7 sẽ KHÔNG được gửi.

Muốn gửi debug:
logging trap debugging

Đây là lỗi rất thường gặp trong doanh nghiệp.

Kỹ sư bật debug nhưng syslog server không nhận gì rồi tưởng firewall chặn.
Kiểm tra syslog server IP


Ví dụ:
logging host 10.1.100.100

Kiểm tra reachability:
ping 10.1.100.100

Nếu ping fail:
  • routing issue
  • default gateway sai
  • VLAN sai
  • interface down

Không có kết nối layer 3 thì syslog không thể hoạt động.
Kiểm tra UDP 514 có bị chặn không


Syslog truyền thống dùng:
UDP 514

Kiểm tra ACL:
show access-lists

Hoặc interface ACL:
show run interface

Ví dụ lỗi:
deny udp any host 10.1.100.100 eq 514

Firewall nội bộ cũng có thể block.
Kiểm tra source interface


Router nhiều interface thường gặp lỗi này.

Ví dụ syslog server chỉ cho phép subnet management:
10.10.10.0/24

Nhưng router lại gửi log từ interface khác:
192.168.1.1

Fix:
logging source-interface Loopback0

Hoặc:
logging source-interface GigabitEthernet0/0
Kiểm tra buffer đầy


Cisco buffer mặc định:
8192 bytes

Quá nhỏ trong môi trường debug.

Output:
Log Buffer (8192 bytes)

Nếu log bị mất:
logging buffered 65536 debugging
SSH/Telnet không thấy log?


Rất nhiều người gặp trường hợp này.

SSH vào router:
ssh admin@router

Bật debug:
debug ip packet

Không thấy gì.

Nguyên nhân:
terminal monitor

chưa bật.

Fix:
terminal monitor
Timestamp sai


Log không có thời gian = ác mộng troubleshooting.

Bật timestamp:
service timestamps log datetime msec
service timestamps debug datetime msec

Dùng NTP:
ntp server 192.168.1.10

Kiểm tra:
show ntp status

Nếu clock sai, correlation giữa firewall / switch / SIEM sẽ rất khó.
Troubleshooting Syslog trên Windows Server


Windows không dùng syslog native theo kiểu Unix.

Thay vào đó dùng:
  • Event Viewer
  • Windows Event Forwarding
  • Syslog Agent
  • SIEM connector

Nếu dùng Kiwi Syslog, NXLog, Syslog-ng agent hoặc Splunk forwarder thì troubleshooting như sau.
Kiểm tra service có chạy không


PowerShell:
Get-Service | findstr -i syslog

Hoặc:
Get-Service nxlog

Nếu stopped:
Start-Service nxlog
Kiểm tra port listening


Syslog receiver thường dùng:
UDP 514
TCP 514

Check:
netstat -ano | findstr 514

Ví dụ:
UDP 0.0.0.0:514

Nếu không có listener thì agent chưa chạy.
Windows Firewall block


Kiểm tra:
Get-NetFirewallRule

Hoặc nhanh:
wf.msc

Cho phép:
  • UDP 514
  • TCP 514

Ví dụ:
New-NetFirewallRule -DisplayName "Syslog UDP" `
-Direction Inbound `
-Protocol UDP `
-LocalPort 514 `
-Action Allow
Kiểm tra Event Viewer


Nếu app báo lỗi nhưng syslog không có:
eventvwr.msc

Xem:
  • System
  • Application
  • Security

Nếu Windows event có nhưng syslog server không có → lỗi ở forwarding layer.
Test connectivity

Test-NetConnection 10.1.100.100 -Port 514

Nếu fail:
  • firewall
  • routing
  • server unreachable
Kiểm tra cấu hình agent


Ví dụ NXLog:
C:\Program Files\nxlog\conf\nxlog.conf

Lỗi thường gặp:

Sai destination:
Host 10.1.100.200

thay vì:
10.1.100.100

Sai protocol:

TCP vs UDP mismatch.
Troubleshooting Syslog trên Linux


Linux là môi trường syslog “chuẩn”.

Thường dùng:
  • rsyslog
  • syslog-ng
  • journald
Kiểm tra service


Rsyslog:
systemctl status rsyslog

Khởi động:
sudo systemctl start rsyslog

Enable boot:
sudo systemctl enable rsyslog
Kiểm tra port listening

ss -lunp | grep 514

hoặc:
netstat -ulnp | grep 514

Nếu không thấy:

service chưa bind.
Kiểm tra config


Rsyslog:
/etc/rsyslog.conf

hoặc:
/etc/rsyslog.d/

Ví dụ enable UDP:
module(load="imudp")
input(type="imudp" port="514")

TCP:
module(load="imtcp")
input(type="imtcp" port="514")

Reload:
systemctl restart rsyslog
Firewall block


Ubuntu:
ufw status

Allow:
ufw allow 514/udp

RHEL/CentOS:
firewall-cmd --list-all

Allow:
firewall-cmd --add-port=514/udp --permanent
firewall-cmd --reload
SELinux block


RHEL thường dính lỗi này.

Check:
getenforce

Nếu:
Enforcing

thì có thể SELinux đang block syslog binding.

Check audit:
ausearch -m avc
Test gửi log thủ công


Cực kỳ hữu ích.
logger "Test syslog message"

Remote:
logger -n 10.1.100.100 -P 514 "Remote syslog test"

Nếu test thành công nhưng app log không tới → lỗi ở application.
Theo dõi realtime

tail -f /var/log/syslog

hoặc:
journalctl -f
Tư duy troubleshooting thực chiến


Khi syslog lỗi, đi theo flow:

1. Service có chạy không?

Nếu không, sửa service.

2. Port có listen không?

Nếu không, cấu hình receiver.

3. Có network reachability không?

Ping / traceroute.

4. Firewall / ACL có block không?

UDP 514 là nghi phạm hàng đầu.

5. Severity đúng chưa?

Rất nhiều log “mất tích” vì filter level.

6. Timestamp đúng chưa?

Correlation trong SIEM phụ thuộc vào thời gian chính xác.

7. Source IP đúng chưa?

Đặc biệt trên router/firewall nhiều interface.
Kết luận cho bài Syslog


Syslog troubleshooting không khó nếu đi đúng quy trình.

Phần lớn sự cố rơi vào vài nhóm quen thuộc:
  • logging chưa bật
  • severity sai
  • UDP 514 bị chặn
  • source interface sai
  • service receiver không chạy
  • firewall/SELinux block
  • timestamp lệch

Trong SOC, NOC, hoặc hạ tầng enterprise, một hệ thống logging không ổn định gần như đồng nghĩa với việc “bay mù”.

Không có log, troubleshooting chỉ là phỏng đoán.​]]> Thiết bị mạng - Unix - Microsoft dangquangminh https://www.forum.vnpro.org/forum/giải-pháp-mạng/thiết-bị-mạng/440164-syslog-troubleshooting Dns https://www.forum.vnpro.org/forum/giải-pháp-mạng/thiết-bị-mạng/440063-dns Sat, 09 May 2026 06:20:49 GMT Triển khai và Quản lý Dịch vụ DNS Trong hạ tầng CNTT hiện đại, DNS (Domain Name System) là một trong những dịch vụ nền tảng quan trọng nhất. Nếu... Triển khai và Quản lý Dịch vụ DNS


Trong hạ tầng CNTT hiện đại, DNS (Domain Name System) là một trong những dịch vụ nền tảng quan trọng nhất. Nếu không có DNS, người dùng sẽ phải nhớ địa chỉ IP thay vì tên miền dễ đọc như google.com hay vnpro.vn. Trong môi trường doanh nghiệp, DNS không chỉ phục vụ phân giải tên mà còn là thành phần sống còn của Active Directory Domain Services (AD DS).

Trong bài học này, chúng ta sẽ đi từ kiến thức nền tảng đến triển khai thực tế dịch vụ DNS trên Windows Server. Tổng quan bài học


Các nội dung chính bao gồm:
  • DNS components (Các thành phần của DNS)
  • DNS zones là gì?
  • DNS records là gì?
  • Demo cài đặt và cấu hình DNS role
  • Quản lý DNS services
  • Tạo DNS records
  • Cấu hình DNS zones
  • DNS forwarding
  • DNS tích hợp với Active Directory Domain Services (AD DS)
  • Tổng quan DNS Policies
  • Giới thiệu DNSSEC
1. DNS Components – Các thành phần của DNS


Một hệ thống DNS hoàn chỉnh gồm nhiều thành phần phối hợp với nhau: DNS Server


Máy chủ DNS chịu trách nhiệm lưu trữ cơ sở dữ liệu DNS và trả lời truy vấn phân giải tên.

Ví dụ:
  • Client hỏi: www.vnpro.vn = ?
  • DNS Server trả lời: 103.x.x.x

DNS server có thể đóng vai trò:
  • Authoritative DNS Server → nắm thông tin chính thức của zone
  • Recursive Resolver → thay mặt client đi truy vấn các DNS khác
DNS Client (Resolver)


Đây là máy tính người dùng hoặc server gửi yêu cầu phân giải tên.

Ví dụ:
ping google.com

Máy client sẽ gửi truy vấn DNS để tìm IP của google.com.
DNS Zone


Zone là vùng quản lý dữ liệu DNS.

Ví dụ:

Domain:
vnpro.vn

Có thể chứa:
www.vnpro.vn
mail.vnpro.vn
vpn.vnpro.vn
dc01.vnpro.vn

Zone là nơi chứa các bản ghi DNS.
DNS Records


Là các bản ghi ánh xạ tên ↔ thông tin mạng.

Ví dụ:

A Record
www.vnpro.vn → 192.168.1.10

MX Record
mail server của domain

CNAME
ftp.vnpro.vn → fileserver.vnpro.vn
2. DNS Zones là gì?


DNS zone là phần dữ liệu DNS mà một DNS server chịu trách nhiệm quản lý.

Có thể hiểu:
  • Domain là namespace logic
  • Zone là database thực tế

Ví dụ:

Domain:
company.local

Zone:
company.local

Chứa:
dc01.company.local
fileserver.company.local
printer.company.local
Các loại DNS Zone

Primary Zone


Zone chính.

Cho phép đọc/ghi.

Lưu bản sao chính thức của DNS database.

Ví dụ:
company.local

được lưu trên:
DC01
Secondary Zone


Bản sao chỉ đọc.

Dùng cho redundancy.

Dữ liệu lấy từ Primary bằng Zone Transfer.

Ví dụ:
DC02

nhận dữ liệu từ:
DC01
Stub Zone


Không chứa toàn bộ database.

Chỉ chứa:
  • SOA
  • NS
  • glue A records

Dùng để hỗ trợ name resolution giữa các domain.
AD-Integrated Zone


Zone lưu trong Active Directory thay vì file text.

Ưu điểm:
  • Multi-master replication
  • Secure dynamic update
  • Không cần zone transfer kiểu truyền thống

Đây là kiểu phổ biến trong domain enterprise.
3. DNS Records là gì?


Các record phổ biến: A Record


Ánh xạ tên → IPv4

Ví dụ:
server01.vnpro.local → 10.10.10.10
AAAA Record


Tên → IPv6

Ví dụ:
server01 → 2001:db8::10
CNAME


Alias.

Ví dụ:
www → web01
MX


Mail server.

Ví dụ:
vnpro.vn → mail.vnpro.vn
NS


Name Server.

Cho biết DNS server authoritative cho zone.

Ví dụ:
ns1.vnpro.vn
PTR


Reverse lookup.

IP → Name

Ví dụ:
10.10.10.10 → server01
SRV


Cực kỳ quan trọng với Active Directory.

Ví dụ:

AD clients dùng record này để tìm:
  • Domain Controller
  • Kerberos
  • LDAP

Ví dụ:
_ldap._tcp.dc._msdcs.company.local

Nếu record này lỗi → domain join fail.
4. Demo: Cài DNS Role trên Windows Server


GUI:

Server Manager
→ Add Roles and Features

Chọn:
DNS Server

Hoặc PowerShell:
Install-WindowsFeature DNS -IncludeManagementTools

Kiểm tra:
Get-WindowsFeature DNS
5. Quản lý DNS Service


Khởi động / dừng dịch vụ:
Restart-Service DNS
Stop-Service DNS
Start-Service DNS

Kiểm tra trạng thái:
Get-Service DNS
6. Tạo DNS Record


Ví dụ tạo A record:
Add-DnsServerResourceRecordA `
-Name "web01" `
-ZoneName "vnpro.local" `
-IPv4Address "10.10.10.20"

Kiểm tra:
Resolve-DnsName web01.vnpro.local
7. DNS Forwarding


DNS nội bộ thường không tự resolve Internet.

Nó sẽ forward query ra DNS upstream.

Ví dụ:

Forwarder:
8.8.8.8
1.1.1.1

PowerShell:
Add-DnsServerForwarder -IPAddress 8.8.8.8
8. DNS và Active Directory


AD phụ thuộc mạnh vào DNS.

Không phải optional.

Là mandatory.

AD dùng DNS để:
  • Tìm Domain Controller
  • LDAP lookup
  • Kerberos auth
  • Global Catalog discovery
  • Replication partner discovery

Ví dụ:

Khi join domain:
company.local

Client sẽ query:
_ldap._tcp.dc._msdcs.company.local

Nếu DNS sai:
  • Không join domain được
  • GPO fail
  • Login domain fail
  • Replication fail
9. DNS Policies


Windows Server DNS hỗ trợ policy-based behavior.

Ví dụ:
  • Geo-location responses
  • Split-brain DNS
  • Traffic management
  • Filtering queries

Ứng dụng:

Internal user:
app.company.local → 10.1.1.10

External user:
app.company.local → 203.x.x.x
10. DNSSEC


DNS truyền thống không xác thực dữ liệu.

Có thể bị:
  • spoofing
  • cache poisoning
  • forged response

DNSSEC thêm:
  • authenticity
  • integrity
  • trust chain

Dùng:
  • digital signatures
  • DNSKEY
  • RRSIG
  • DS records

Nhưng cần quản lý key lifecycle cẩn thận.
Kết luận


DNS là dịch vụ nền tảng của hầu hết mọi hệ thống enterprise.

Nếu hiểu DNS tốt, bạn sẽ dễ dàng làm việc với:
  • Active Directory
  • Exchange
  • Web services
  • Cloud hybrid environments
  • Security troubleshooting

Một System Engineer giỏi gần như chắc chắn phải rất vững DNS.

Bởi vì khi DNS lỗi…

mọi thứ trông giống như mạng bị hỏng.
​
​]]> Thiết bị mạng - Unix - Microsoft dangquangminh https://www.forum.vnpro.org/forum/giải-pháp-mạng/thiết-bị-mạng/440063-dns