Tải bản đầy đủ (.docx) (31 trang)

QUẢN TRỊ MẠNG GIAO THỨC SNMP

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (1.06 MB, 31 trang )

MỤC LỤC


DANH MỤC HÌNH ẢNH


LỜI MỞ ĐẦU
Với sự phát triển các máy trạm, các máy chủ và mạng LAN đã làm thay đổi
mạng máy tính liên tục. Mặt khác với sự phát triển mạnh mẽ của các hệ thống và thiết
bị, phần mềm của các nhà sản xuất khác nhau; sự mua bán các hệ thống và thiết bị,
phần mềm của các nhà sản xuất. Do vậy các nhà sản xuất thiết bị hoặc phần mềm phải
cung cấp phần mềm giao tiếp với thiết bị để có thể cấu hình và quản lý chúng. Và như
vậy, mỗi một nhà sản xuất ít nhất phải có một phần mềm quản lý riêng với nguyên tắc
hoạt động riêng cho sản phẩm của mình. Điều này gây ra nhiều bất tiện. Do vậy, người
ta xây dựng các giao thức quản lý thiết bị chung cho tất cả các nhà sản xuất. Trong các
giao thức đó thì giao thức được biết đến nhiều nhất là giao thức SNMP (Simple
Netword Management Protocol). Các thiết bị dù đơn giản hay phức tạp đều chứa phần
mềm SNMP dùng để tham gia vào việc quản lý mạng.
Môn học “Quản trị mạng máy tính” là môn học cung cấp cho sinh viên các kiến
thức về các giao thức quản lý mạng cũng như các phần mềm, công cụ cần thiết để
quản lý hệ thống mạng. Nắm bắt được trạng thái hệ thống mạng để đảm bảo hệ thống
mạng được hoạt động xuyên suốt.... Vì vậy, việc tìm hiểu lý thuyết về các giao thức
quản lý mạng cũng như chọn công cụ thích hợp để nghiên cứu, thực hành trong quá
trình học tập là điều không thể thiếu.
Với mục đích và ý nghĩa trên, nhóm 2 lớp D3A đã lựa chọn đề tài “Tìm hiểu về
giao thức quản lý mạng SNMP”. Nội dung của đề tài chia làm ba chương:
Chương 1: Tổng quan về giao thức SNMP.
Chương 2: Thành phần và các chức năng của SNMP.
Chương 3: Cài đặt và thực hiện việc giám sát trên phần mềm.
Trong quá trình làm báo cáo chắc chắn không tránh khỏi thiếu sót. Mong các
thầy cô và các bạn đóng góp ý kiến để báo cáo được hoàn thiện hơn. Xin chân thành


cảm ơn!

3


Chương 1. TỔNG QUAN VỀ QUẢN TRỊ MẠNG VỚI GIAO THỨC SNMP
Mục đích của chương này là cung cấp cho chúng ta những khái niệm cơ bản
nhất về giao thức quản lí mạng đơn giản SNMP, các thành phần, chức năng và phương
thức hoạt động của giao thức.
Phần đầu chương giới thiệu tổng quan về SNMP, cấu trúc và đặc điểm cũng như
hoạt động của giao thức này. Sau đó giới thiệu các phiên bản sau của SNMP và phân
tích được những khác biệt của các phiên bản sau với phiên bản SNMP đầu tiên.
1.1. Khái niệm quản trị mạng
* Quản trị mạng là quá trình điều khiển các hệ thống mạng, nhằm tối ưu hóa
năng suất và hiệu quả của hệ thống mạng.
* Quản trị mạng gồm các công việc như:
- Thiết lập cấu hình, quản trị tài nguyên: bao gồm việc quản lí, thiết lập cấu hình,
quản lí tài nguyên với các đối tượng khác nhau.
- Quản trị người dùng và các dịch vụ mạng: bao gồm việc quản trị các tài khoản
người dùng trên hệ thống và bảo đảm các dịch vụ hoạt động ổn định đúng tiêu chuẩn.
- Quản trị hiệu suất hệ thống mạng: bao gồm việc quản lí, giám sát hoạt động,
đảm bảo hoạt động các thành phần hệ thống ổn định.
- Quản trị bảo mật, an toàn mạng: bao gồm việc giám sát, bảo mật và khắc phục
sự cố mạng giúp các hệ thống để đảm bảo phòng tránh các truy nhập trái phép.
* Quản trị mạng bao gồm 2 thành phần chính: Quản trị mạng cỡ nhỏ và quản trị
mạng cỡ lớn
- Quản trị mạng cỡ nhỏ cũng cần có nhiều kiến thức ở mức độ kỹ thuật viên như
sửa chữa máy tính, sử dụng thành thạo WINDOWS SERVER 2003, WinXP, Windows
7. Ngoài Windows server thì biết quản trị hệ thống mạng Linux cũng là một lợi thế
lớn. Thực tế thì quản trị mạng Microsoft vẫn chiếm phần lớn.

- Quản trị mạng cỡ lớn thì cần đến nền tảng kiến thức vững vàng, ngoài ra còn
cần có kinh nghiệm và kiến thức mạng sâu, qua học tập và thực tế lâu dài mới có được.
Để quản trị một hệ thống như vậy trước tiên phải nắm rõ kiến thức nền ở mức độ
CCNA, bên cạnh đó cũng cần tiếp xúc với các thiết bị mạng của Cisco hay các hãng
lớn như Nortel, Alcatel,… Để quản trị một trung tâm dữ liệu (Data center) thì bắt buộc
phải có rất nhiều kiễn thức và kinh nghiệm về Unix, Sun, Firewall…
1.2. Hai phương thức giám sát Poll và Alert
Đây là hai phương thức cơ bản của các kỹ thuật giám sát hệ thống, nhiều phần
mềm và giao thức được xây dựng dựa trên hai phương thức này, trong đó có SNMP.
Việc hiểu rõ hoạt động của Poll & Alert và ưu nhược điểm của chúng sẽ giúp chúng ta
dễ dàng tìm hiểu nguyên tắc hoạt động của các giao thức hay phần mềm giám sát.
Hoặc nếu muốn tự phát triển một cơ chế giám sát của riêng mình thì nó cũng là cơ sở
để giúp chúng ta xây dựng một nguyên tắc hoạt động đúng đắn.
1.2.1. Phương thức Poll
Nguyên tắc hoạt động: Trung tâm giám sát (manager) sẽ thường xuyên hỏi thông
tin của thiết bị cần giám sát (device). Nếu Manager không hỏi thì Device không trả lời,
nếu Manager hỏi thì Device phải trả lời. Bằng cách hỏi thường xuyên, Manager sẽ
luôn cập nhật được thông tin mới nhất từ Device. Ví dụ: Người quản lý cần theo dõi
4


khi nào thợ làm xong việc. Anh ta cứ thường xuyên hỏi người thợ “Anh đã làm xong
chưa?”, và người thợ sẽ trả lời “Xong” hoặc “Chưa”.

Hình 1.1. Phương thức Poll

1.2.2. Phương thức Alert
Nguyên tắc hoạt động: mỗi khi trong Device xảy ra một sự kiện (event) nào đó
thì Device sẽ tự động gửi thông báo tới Manager, gọi là Alert. Manager không hỏi
thông tin định kì từ Device.

Device chỉ gửi thông báo mang tính sự kiện chứ không gửi những thông tin
thường xuyên thay đổi, nó cũng sẽ không gửi Alert nếu chẳng có sự kiện gì xảy ra.
Chẳng hạn khi một port down/up thì Device sẽ gửi cảnh báo, còn tổng số byte truyền
qua port đó sẽ không được Device gửi đi vì đó là thông tin thường xuyên thay đổi.
Muốn lấy những thông tin thường xuyên thay đổi thì Manager phải chủ động đi hỏi
Device, tức là phải thực hiện phương thức Poll.

Hình 1.2. Phương thức Alert

1.2.3. So sánh giữa phương thức Poll và Alert
POLL
ALERT
Có thể chủ động lấy những thông tin cần Tất cả những event xảy ra đều được gửi về
thiết từ các đối tượng mình quan tâm, manager. Manager phải có cơ chế lọc
không cần lấy những thông tin không cần những event cần thiết hoặc device phải
thiết từ những nguồn không quan tâm.
thiết lập được cơ chế chỉ gửi những event
cần thiết.
Có thể lập bảng trạng thái tất cả các thông Nếu không có event gì xảy ra thì manager
5


tin của device sau khi poll một lượt các
thông tin đó.
Trong trường hợp thường xuyên giữa
Manager và device xảy ra gián đoạn và
device có sự thay đổi thì manager sẽ
không thể cập nhật. Tuy nhiên khi đường
truyền thông suốt trở lại thì manager sẽ
cập nhật được thông tin mới nhất do nó

luôn luôn poll định kì.
Chỉ cần cài đặt tại manager để trỏ đến tất
cả device. Có thể dễ dàng thay đổi một
manager khác.

không biết được trạng thái của device.
Khi đường truyền gián đoạn và device có
sự thay đổi thì nó vẫn gửi alert cho
manager, nhưng alert này sẽ không đến
được manager. Sau đó dù đường truyền có
thông suốt trở lại thì manager cũng không
biết được điều gì đã xảy ra.
Phải cài đặt tại từng device để trỏ đến
manager. Khi thay đổi manager thì phải
cài đặt lại trên tất cả device để trỏ về
manager mới.
Ngay khi có sự kiện xảy ra thì device sẽ
gửi alert đến manager. Do đó manager
luôn luôn có những thông tin mới nhất tức
thời.

Nếu tần suất poll thấp, thời gian chờ giữa
hai chu kì poll (polling interval) dài sẽ làm
manager chậm cập nhật các thay đổi của
device. Nghĩa là nếu thông tin device đã
thay đổi nhưng vẫn chưa đến lượt poll kế
tiếp thì manager vẫn giữ được thông tin
cũ.
Có thể bỏ sót các sự kiện: khi device có Manager sẽ được thông báo mỗi khi có sự
thay đổi, sau đó thay đổi trở lại như ban kiện xảy ra ở device, dó đó manager sẽ

đầu trước khi đến lượt poll kế tiếp thì không bỏ sót bất cứ sự kiện nào.
manager sẽ không phát hiện được.
1.3. Giao thức SNMP
Vào đầu năm 1988, Tổ chức kiến trúc internet IAB (Internet Architecture Board)
nhận thấy sự cần thiết có bộ công cụ quản lí cho TCP/IP nên đã cho ra đời RFC 1052.
RFC 1052 là các yêu cầu tiêu chuẩn hoá quản lí mạng và tập trung vào các vấn đề
quản lí mạng phải thực hiện:
- Đảm bảo tính mở rộng.
- Đảm bảo tính đa dạng để phát triển.
- Đảm bảo tính đa dạng trong quản lí.
- Bao trùm nhiều lớp giao thức.
Tháng 4 năm 1993, SNMPv2 trở thành tiêu chuẩn quản lí mạng đơn giản thay thế
SNMPv1. SNMPv2 bổ sung một số vấn đề mà SNMPv1 còn thiếu như nhận thực và
bảo mật. Tuy nhiên, SNMPv2 khá phức tạp và khó tương thích với SNMPv1.
Năm 1997, SNMPv3 ra đời nhằm tương thích với các giao thức đa phương tiện
trong quản lí mạng, phát triển trên nền java và đưa ra kiến trúc và giao thức mới như
giao thức quản lí đa phương tiện HMMP (Hypermedia Management Protocol).
1.3.1. Khái niệm
SNMP là “giao thức quản lý mạng đơn giản”, dịch từ cụm từ “Simple Network
Management Protocol”.
Thế nào là giao thức quản lý mạng đơn giản? Giao thức là một tập hợp các thủ
tục mà các bên tham gia cần tuân theo để có thể giao tiếp được với nhau. Trong lĩnh
vực thông tin, một giao thức quy định cấu trúc, định dạng (format) của dòng dữ liệu
6


trao đổi với nhau và quy định trình tự, thủ tục để trao đổi dòng dữ liệu đó. Nếu một
bên tham gia gửi dữ liệu không đúng định dạng hoặc không theo trình tự thì các bên
khác sẽ không hiểu hoặc từ chối trao đổi thông tin. SNMP là một giao thức, vì vậy nó
có những quy định riêng mà các thành phần trong mạng phải tuân theo.

Một thiết bị hiểu được và hoạt động tuân theo giao thức SNMP được gọi là “có
hỗ trợ SNMP” (SNMP supported) hoặc “tương thích SNMP” (SNMP compartible).
SNMP dùng để quản lý, nghĩa là có thể theo dõi, lấy thông tin, được thông báo,
và tác động để hệ thống hoạt động như ý muốn. VD một số khả năng của phần mềm
SNMP :
- Theo dõi tốc độ đường truyền của một router, biết được tổng số byte đã
truyền/nhận.
- Lấy thông tin máy chủ đang có bao nhiêu ổ cứng, mỗi ổ cứng còn trống bao
nhiêu.
- Tự động nhận cảnh báo khi switch có một port bị down.
- Điều khiển tắt (shutdown) các port trên switch.
SNMP dùng để quản lý mạng, nghĩa là nó được thiết kế để chạy trên nền TCP/IP
và quản lý các thiết bị có nối mạng TCP/IP. Các thiết bị mạng không nhất thiết phải là
máy tính mà có thể là switch, router, firewall, adsl gateway, và cả một số phần mềm
cho phép quản trị bằng SNMP. Giả sử bạn có một cái máy giặt có thể nối mạng IP và
nó hỗ trợ SNMP thì bạn có thể quản lý nó từ xa bằng SNMP.
SNMP là giao thức đơn giản, do nó được thiết kế đơn giản trong cấu trúc bản tin
và thủ tục hoạt động, và còn đơn giản trong bảo mật (ngoại trừ SNMP version 3). Sử
dụng phần mềm SNMP, người quản trị mạng có thể quản lý, giám sát tập trung từ xa
toàn mạng của mình.
1.3.2. Ưu điểm sử dụng giao thức SNMP
SNMP được thiết kế để đơn giản hóa quá trình quản lý các thành phần trong
mạng. Nhờ đó các phần mềm SNMP có thể được phát triển nhanh và tốn ít chi phí.
SNMP được thiết kế để có thể mở rộng các chức năng quản lý, giám sát. Khi có một
thiết bị mới với các thuộc tính, tính năng mới thì người ta có thể thiết kế tùy chọn
SNMP để phục vụ cho riêng mình. SNMP được thiết kế để có thể hoạt động độc lập
với các kiến trúc và cơ chế của các thiết bị hỗ trợ SNMP. Các thiết bị khác nhau có
hoạt động khác nhau nhưng hoạt động dựa trên giao thức SNMP là giống nhau.
VD: Bạn có thể dùng một phần mềm để theo dõi dung lượng ổ cứng còn trống
của các máy chủ chạy HĐH Windows và Linux; trong khi nếu không dùng SNMP mà

làm trực tiếp trên các HĐH này thì bạn phải thực hiện theo các cách khác nhau.
1.3.3. Các phiên bản SNMP
Hiện tại SNMP có 3 phiên bản: SNMPv1, SNMPv2 và SNMPv3. Các phiên bản
này khác nhau một chút ở định dạng bản tin và phương thức hoạt động. Hiện nay
SNMPv1 là phổ biến nhất do có nhiều thiết bị tương thích nhất và có nhiều phần mềm
hỗ trợ nhất. Trong khi đó chỉ có một số thiết bị và phần mềm hỗ trợ SNMPv3.
a. Phiên bản SNMPv1
Phiên bản đầu tiên của SNMP, có 5 phương thức Get, GetNext, Set, Response,
Trap.
7


- GetRequest: Bản tin GetRequest được manager gửi đến agent để lấy một thông
tin nào đó. Trong GetRequest có chứa ID của object muốn lấy. Ví dụ: Muốn lấy thông
tin tên của Device1 thì manager gửi bản tin GetRequest ID=1.3.6.1.2.1.1.5 đến
Device1, tiến trình SNMP agent trên Device1 sẽ nhận được bản tin và tạo bản tin trả
lời. Trong một bản tin GetRequest có thể chứa nhiều OID, nghĩa là dùng một
GetRequest có thể lấy về cùng lúc nhiều thông tin.
- GetNextRequest: Bản tin GetNextRequest cũng dùng để lấy thông tin và cũng
có chứa OID, tuy nhiên nó dùng để lấy thông tin của object nằm kế tiếp object được
chỉ ra trong bản tin. Chúng ta đã biết khi đọc qua những phần trên: một MIB bao gồm
nhiều OID được sắp xếp thứ tự nhưng không liên tục, nếu biết một OID thì không xác
định được OID kế tiếp. Do đó ta cần GetNextRequest để lấy về giá trị của OID kế tiếp.
Nếu thực hiện GetNextRequest liên tục thì ta sẽ lấy được toàn bộ thông tin của agent.
- SetRequest: Bản tin SetRequest được manager gửi cho agent để thiết lập giá trị
cho một object nào đó. Ví dụ: Có thể đặt lại tên của một máy tính hay router bằng
phần mềm SNMP manager, bằng cách gửi bản tin SetRequest có OID là
1.3.6.1.2.1.1.5.0 (sysName.0) và có giá trị là tên mới cần đặt.
- GetResponse: Mỗi khi SNMP agent nhận được các bản tin GetRequest,
GetNextRequest hay SetRequest thì nó sẽ gửi lại bản tin GetResponse để trả lời. Trong

bản tin GetResponse có chứa OID của object được request và giá trị của object đó.
- Trap: Bản tin Trap được agent tự động gửi cho manager mỗi khi có sự kiện xảy
ra bên trong agent, các sự kiện này không phải là các hoạt động thường xuyên của
agent mà là các sự kiện mang tính biến cố. Ví dụ: Khi có một port down, khi có một
người dùng login không thành công, hoặc khi thiết bị khởi động lại, agent sẽ gửi trap
cho manager. Tuy nhiên không phải mọi biến cố đều được agent gửi trap, cũng không
phải mọi agent đều gửi trap khi xảy ra cùng một biến cố. Việc agent gửi hay không gửi
trap cho biến cố nào là do hãng sản xuất device/agent quy định.

Hình 1.3. Các phương thức trong SNMPv1

* Cấu trúc của PDU GetRequest:
- Request-id: mã số của request. ID này là số ngẫu nhiên do manager tạo ra, agent
khi gửi bản tin GetResponse cho request nào thì nó phải gửi requestID giống như lúc
nhận. Giữa manager và agent có thể có nhiều request & reponse, một request và một
response là cùng một phiên trao đổi khi chúng có requestID giống nhau.
8


- Error-status: nếu = 0 là thực hiện thành công không có lỗi, nếu <> 0 là có lỗi
xảy ra và giá trị của nó mô tả mã lỗi. Trong bản tin GetRequest, GetNextRequest,
SetRequest thì error-status luôn = 0.
- Error-index: số thứ tự của objectid liên quan đến lỗi nếu có. Trong variablebindings có nhiều objectid, được đánh số từ 1 đến n, một bản tin GetRequest có thể lấy
cùng lúc nhiều object.
- Variable-bindings: danh sách các cặp [ObjectID – Value] cần lấy thông tin,
trong đó objectID là định danh của object cần lấy, còn value không mang giá trị. Khi
agent gửi bản tin trả lời thì nó sẽ copy lại bản tin này và điền vào value bằng giá trị của
object.

Hình 1.4. Cấu trúc Get/Getnext/Set/Response PDU


Hình 1.5. Sử dụng WireShark kiểm tra

- Trong hình trên là cấu trúc một bản tin SNMP với PDU là GetRequest. Bao
gồm các thông tin:
9


+ Version là v1, số 0 trong ngoặc là giá trị của trường version, nếu giá trị này là 0
nghĩa là version1.
+ Community là “public”.
+ Request-id = 2142061952.
+ Error-status = 0, nghĩa là không có lỗi. Trong bản tin GetResponse thì errorstatus mới được dùng.
+ Error-index = 0.
+ Phần variable-bindings bao gồm 1 item, mỗi item là 1 cặp objectid-value.
+ Objectid là .1.3.6.1.2.1.1.3.0, theo mib-2 thì đó là sysUpTime.0
+ Scalar instance index = 0, đây là chỉ số index của sysUptime. Do một thiết bị
chỉ có một khái niệm sysUptime nên index là 0 (sysUptime.0). Nếu bạn request
ifDescr chẳng hạn thì mỗi interface sẽ có một description khác nhau và sẽ có index
khác nhau.
+ value = unSpecified. Do bản tin là GetRequest nên value sẽ không mang giá
trị, giá trị sẽ được ghi vào và trả về trong bản tin GetResponse.
* Cấu trúc của PDU GetResponse: Cấu trúc GetNextRequest giống với
GetRequest, chỉ khác ở byte chỉ ra bản tin là GetNextRequest PDU. Hình sau là bản
tin GetNextRequest với objectID là sysContact, sau đó agent sẽ gửi bản tin
GetReponse trả lời với objectID là sysName, vì sysName nằm sau sysContact trong
MIB. Chú ý request-id là giống nhau.

Hình 1.6. Cấu trúc get-next


* Cấu trúc của PDU SetRequest: Cấu trúc SetRequest cũng giống với
GetRequest, objectID-value chỉ ra đối tượng và giá trị cần thiết lập.

10


Hình 1.7. Cấu trúc PDU Setrequest

* Cấu trúc của PDU Trap: Cấu trúc của bản tin trap của SNMPv1 như sau:
- Enterprise: kiểu của object gửi trap. Đây là một OID giúp nhận dạng thiết bị
gửi trap là thiết bị gì; nhận dạng chi tiết đến hãng sản xuất, chủng loại, model. OID
này bao gồm một chỉ số doanh nghiệp (enterprise number) và chỉ số id của thiết bị của
hãng do hãng tự định nghĩa.
- Agent address: địa chỉ IP của nguồn sinh ra trap. Có thể bạn sẽ thắc mắc tại sao
lại có IP của nguồn sinh ra trap trong khi bản tin IP chứa gói SNMP đã có địa chỉ
nguồn. Giả sử mô hình giám sát của bạn như sau: tất cả trap sender được cấu hình để
gửi trap đến một trap receiver trung gian, gọi là trap relay, sau đó trap relay mới gửi
đến nhiều trap receiver cùng lúc thì lúc này bản tin trap nhận được tại trap receiver sẽ
có IP source là của trap relay, trong khi IP của nguồn phát sinh trap thực sự nằm trong
agent address.
- Generic-trap: kiểu của các loại trap generic.
- Specific-trap: kiểu của các loại trap do người dùng tự định nghĩa.
- Time-stamp: thời gian tính từ lúc thiết bị được khởi động đến lúc gửi bản tin
trap, tính bằng centi giây.
- Variable-bindings: các cặp objectID - values mô tả các object có liên quan đến
trap.
b. Phiên bản SNMPv2
SNMPv2 tích hợp khả năng liên điều hành từ manager tới manager và hai đơn vị
dữ liệu giao thức mới. Khả năng liên kết điều hành manager - manager cho phép
SNMP hỗ trợ quản lí mạng phân tán trong một trạm và gửi báo cáo tới một trạm khác.

Hai đơn vị dữ liệu giao thức PDU (Protocol Data Unit) là GetbulkRequest và
InformRequest. Các PDU này liên quan tới xử lý lỗi và khả năng đếm của SNMPv2.
Khả năng đếm trong SNMPv2 sử dụng bộ đếm 64 bit (hoặc 32) để duy trì trạng thái
của các liên kết và giao diện.
MIB cho SNMPv2: MIB trong SNMPv2 định nghĩa các đối tượng mô tả tác động
của một phần tử SNMPv2.
MIB gồm 3 nhóm:
11


- Nhóm hệ thống (System group): là một mở rộng của nhóm system trong MIB-II
gốc, bao gồm một nhóm các đối tượng cho phép một Agent SNMPv2 mô tả các đối
tượng tài nguyên của nó.
- Nhóm SNMP (SNMP group): một cải tiến của nhóm SNMP trong MIB-II gốc,
bao gồm các đối tượng cung cấp các công cụ cơ bản cho hoạt động giao thức.
- Nhóm các đối tượng MIB (MIB objects group): một tập hợp các đối tượng liên
quan đến các SNMPv2-trap PDU và cho phép một vài phần tử SNMPv2 cùng hoạt
động, thực hiện như trạm quản trị, phối hợp việc sử dụng của chúng trong toán tử Set
của SNMPv2
Nhóm hệ thống: nhóm system định nghĩa trong SNMPv2 giống trong MIB-II và
bổ sung một vài đối tượng mới.
Nhóm SNMP: nhóm này gần giống như nhóm SNMP đươc định nghĩa trong
MIB-II nhưng có thêm một số đối tượng mới và loại bỏ một số đối tượng ban đầu.
Nhóm SNMP chứa một vài thông tin lưu lượng cơ bản liên quan đến toán tử SNMPv2
và chỉ có một trong các đối tượng là bộ đệm chỉ đọc 32-bit.
Nhóm đối tượng MIB: nhóm các đối tượng MIB chứa các đối tượng thích hợp
thêm vào việc điều khiển các đối tượng MIB.

Hình 1.8. Cấu trúc bản tin SNMPv2


* Cấu trúc bản tin SNMPv2: Trường phiên bản (Version) thể hiện phiên bản
của giao thức SNMPv2.
Trường Community là một chuỗi password xác nhận cho cả tiến trình lấy và
thay đổi dữ liệu. SNMP PDU chứa kiểu điều hành (get, set), yêu cầu đáp ứng (cùng số
thứ tự với bản tin gửi đi) - cho phép người điều hành gửi đồng thời nhiều bản tin. Biến
ghép gồm các thiết bị được đặc tả trong RFC 2358 và chứa cả giá trị đặt tới đối tượng.
Trường đơn vị dữ liệu giao thức (PDU) gồm có các trường con: Kiểu đơn vị dữ
liệu giao thức, nhận dạng các yêu cầu (Request ID), trạng thái lỗi, chỉ số lỗi, các giá trị
và đối tượng.
Các kiểu đơn vị dữ liệu giao thức PDU thể hiện các bản tin sử dụng trong
SNMPv2 gồm có:
GetRequest: Câu lệnh GetRequest được sử dụng giữa Manager tới Agent. Câu
lệnh này được sử dụng để đọc biến MIB đơn hoặc danh sách các biến MIB từ các
Agent đích.
12


GetNextRequest: Câu lệnh GetNextRequest tương tự như câu lệnh GetRequest,
tuy nhiên tuỳ thuộc vào agent trong khoản mục kế tiếp của MIB. Các biến được lưu
trong thiết bị và được coi như đối tượng bị quản lí. Vì vậy, câu lệnh GetNextRequest
mở rộng các biến và được đọc theo tuần tự.
SetRequest: Câu lệnh SetRequest là câu lệnh được gửi đi từ Manager tới Agent
như hai câu lệnh trên. SetRequest tìm kiếm các thông tin mở rộng trongbảng MIB và
yêu cầu Agent đặt giá trị cho các đối tượng quản lý hoặc các đối tượng chứa trong câu
lệnh.
GetResponse: Câu lệnh GetResponse là câu lệnh từ Agent tới Manager. Câu
lệnh này cung cấp cơ chế đáp ứng cho các câu lệnh GetRequest, GetNextRequest và
SetRequest.
Trap: Trap là câu lệnh độc lập, không phụ thuộc vào đáp ứng hoặc yêu cầu từ
các Manager hoặc các Agent. Trap đưa ra các thông tin liên quan tới các điều kiện

được định nghĩa trước và được gửi từ các Agent tới Manager.
GetBulkRequest: Chức năng của câu lệnh GetBulkRequest tương tự như câu
lệnh GetNextRequest ngoại trừ vấn đề liên quan tới số lượng dữ liệu được lấy ra.
GetBulkRequest cho phép Agent gửi lại Manager dữ liệu liên quan tới nhiều đối tượng
thay vì từng đối tượng bị quản lý. Như vậy, GetBulkRequest có thể giảm bớt lưu lượng
truyền dẫn và các bản tin đáp ứng thông báo về các điều kiện vi phạm.
InformRequest: Câu lệnh InformRequest cung cấp khả năng hỗ trợ các Manager
bố trí theo cấu hình phân cấp.Câu lệnh này cho phép một Manager trao đổi thông tin
với các Manager khác.
Trong trường PDU Type, các giá trị thể hiện như sau:
Bảng 1.1. Thông tin trong trường PDU

Câu lệnh

Giá trị trong trường PDU

GetRequest

0

GetNextRequest

1

Response

2

SetRequest


3

GetBulkRequest

4

InformRequest

5

SNMPv2-Trap

6

Report
7
c. Phiên bản SNMPv3
SNMPv3 dựa trên việc thực hiện giao thức, loại dữ liệu và uỷ quyền như
SNMPv2 và cải tiến phần an toàn. SNMPv3 cung cấp an toàn truy nhập vào các thiết
bị bằng cách kết hợp sự xác nhận và mã khoá các gói tin trên mạng. Những đặc điểm
bảo mật cung cấp trong SNMPv3 là:
Tính toàn vẹn thông tin: Đảm bảo các gói tin không bị sửa trong khi truyền.
Sự xác nhận: Xác nhận nguồn của thông tin gửi đến.
Mã khoá: Đảo nội dung của gói tin, ngăn cản việc gửi thông báo từ nguồn không
được xác nhận.
13


Tuy nhiên việc sử dụng SNMPv3 rất phức tạp và cồng kềnh, dù nó là sự lựa chọn
tốt nhất cho vấn đề bảo mật của mạng. Việc sử dụng sẽ tốn rất nhiều tài nguyên do

trong mỗi bản tin truyền đi sẽ có phần mã hóa BER. Phần mã hóa này sẽ chiếm một
phần băng thông đường truyền, do đó làm tăng phí tổn mạng. Mặc dù được coi là
phiên bản đề nghị cuối cùng và được coi là đầy đủ nhất nhưng SNMPv3 vẫn chỉ là tiêu
chuẩn dự thảo và vẫn đang được nghiên cứu hoàn thiện.
Khuôn dạng bảng tin SNMPv3: RFC 2572 định nghĩa các khuôn dạng bản tin
SNMPv3. Khuôn dạng bản tin SNMPv3 được phân chia trong trong bốn phần:
Dữ liệu chung (Common data): trường này xuất hiện trong tất cả các bản tin
SNMPv3.
Bảo mật mô hình dữ liệu (Security model data): vùng này có ba phần: phần
chung, phần dành cho sự chứng thực và phần cho dữ liệu riêng.
Context: hai trường nhận dạng và tên được dùng để cung cấp context cho PDU
nào sẽ phải xử lý.
PDU: vùng này chứa một SNMPv2c PDU.

14


Chương 2. THÀNH PHẦN VÀ CHỨC NĂNG CỦA SNMP
2.1. Quản lý truyền thông trong SNMP
Hệ thống quản lý mạng dựa trên SNMP gồm ba thành phần: bộ phận quản lý
(manager), thiết bị chịu sự quản lý – còn gọi là đại lý (agent) và cơ sở dữ liệu gọi là cơ
sở thông tin quản lý (MIB). Mặc dù SNMP là một giao thức quản lý việc chuyển giao
thông tin giữa ba thực thể trên, song nó cũng định nghĩa mối quan hệ client-server (chủ
tớ). Cơ sở dữ liệu do agent SNMP quản lý là đại diện cho MIB của SNMP. Minh họa
mối quan hệ giữa ba thành phần SNMP này.

Hình 2.9. Mối quan hệ giữa các thành phần SNMP

2.1.1. Manager
Bộ phận quản lý (Manager) là một chương trình vận hành trên một hoặc nhiều

máy tính trạm.
Tùy thuộc vào cấu hình, mỗi bộ phận quản lý có thể được dùng để quản lý một
mạng con, hoặc nhiều bộ phận quản lý có thể được dùng để quản lý cùng một mạng
con hay một mạng chung. Tương tác thực sự giữa một người sử dụng cuối (end-user)
và bộ phận quản lý được duy trì qua việc sử dụng một hoặc nhiều chương trình ứng
dụng mà, cùng với bộ phận quản lý, biến mặt bằng phần cứng thành trạm quản lý
mạng (NMS). Ngày nay, trong thời kỳ các chương trình giao diện người sử dụng đồ
họa (GUI), hầu hết những chương trình ứng dụng sẽ cho ra giao diện sử dụng con trỏ
và chuột để phối hợp hoạt động với bộ phận quản lý tạo ra những bản đồ họa và biểu
đồ cung cấp những tổng kết hoạt động của mạng dưới dạng thấy được. Qua bộ phận
quản lý, những yêu cầu được chuyển tới một hoặc nhiều thiết bị chịu sự quản lý ban
đầu SNMP được phát triển để sử dụng trên mạng TCP/IP và những mạng này tiếp tục
làm mạng vận chuyển cho phần lớn các sản phẩm quản lý mạng dựa trên SNMP. Tuy
nhiên SNMP cũng có thể được chuyển qua NetWare IPX và những cơ cấu vận chuyển
khác.
2.1.2. Agent
15


Thiết bị chịu sự quản lý (Agent) là một nút mạng hỗ trợ giao thức SNMP và
thuộc về mạng bị quản lý. Thiết bị có nhiệm vụ thu thập thông tin quản lý và lưu trữ để
phục vụ cho hệ thống quản lý mạng. Những thiết bị chịu sự quản lý, đôi khi được gọi
là những phần tử mạng, có thể là các bộ định tuyến và máy chủ truy nhập (Access
Server), switch, bridge, hub và máy tính hay là máy in trong mạng. Mỗi thiết bị chịu
sự quản lý bao gồm phần mềm hoặc phần sụn (firmware) dưới dạng mã phiên dịch
những yêu cầu SNMP và đáp ứng của những yêu cầu đó. Phần mềm hoặc phần sụn
này được coi là một agent. Mặc dù mỗi thiết bị bắt buộc bao gồm một agent chịu quản
lý trực tiếp, những thiết bị không tương thích với SNMP cũng có thể quản lý được nếu
như chúng hỗ trợ một giao thức quản lý độc quyền. Để thực hiện được điều này phải
có agent ủy nhiệm (proxy agent). Proxy agent này có thể được coi như một bộ chuyển

đổi giao thức vì nó phiên dịch những yêu cầu SNMP thành giao thức quản lý độc
quyền của thiết bị không hoạt động theo giao thức SNMP. Mặc dù SNMP chủ yếu là
giao thức đáp ứng thăm dò (poll-respond) với những yêu cầu do bộ phận quản lý tạo ra
dẫn đến những đáp ứng trong agent, agent cũng có khả năng đề xướng ra một “đáp
ứng tự nguyện”. Đáp ứng tự nguyện này là điều kiện cảnh báo từ việc giám sát agent
với hoạt động đã được định nghĩa trước và đáp ứng này cảnh báo việc agent đã tới
ngưỡng định trước. Dưới sự điều khiển SNMP, việc truyền cảnh báo này được gọi là
cái bẫy (TRAP).
2.1.3. Cơ sở thông tin quản lý – MIB (Management Information Base)
Mỗi thiết bị chịu sự quản lý có thể có cấu hình, trạng thái và thông tin thống kê
định nghĩa chức năng và khả năng vận hành của thiết bị. Thông tin này rất đa dạng, có
thể bao gồm việc thiết lập chuyển mạch phần cứng, những giá trị khác nhau lưu trữ
trong các bảng ghi nhớ dữ liệu, bộ hồ sơ hoặc các trường thông tin trong hồ sơ lưu trữ
ở các file và những biến hoặc thành phần dữ liệu tương tự. Nhìn chung, những thành
phần dữ liệu này được coi là cơ sở thông tin quản lý của thiết bị chịu sự quản lý. Xét
riêng, mỗi thành phần dữ liệu biến đổi được coi là một đối tượng bị quản lý và bao
gồm tên, một hoặc nhiều thuộc tính và một tập các hoạt động (operation) thực hiện
trên đối tượng đó. Vì vậy MIB định nghĩa loại thông tin có thể khôi phục từ một thiết
bị chịu sự quản lý và cách cài đặt thiết bị mà hệ thống quản lý điều khiển.
MIB (cơ sở thông tin quản lý) là một cấu trúc dữ liệu gồm các đối tượng được
quản lý (managed object), được dùng cho việc quản lý các thiết bị chạy trên nền
TCP/IP. MIB là kiến trúc chung mà các giao thức quản lý trên TCP/IP nên tuân theo,
trong đó có SNMP. MIB được thể hiện thành 1 file (MIB file), và có thể biểu diễn
thành 1 cây (MIB tree). MIB có thể được chuẩn hóa hoặc tự tạo.

16


Mô hình cây MIB:


Hình 2.10. Minh họa cây MIB

Một node trong cây là một đối tượng (object), có thể được gọi bằng tên hoặc id.
Ví dụ:
- Node iso.org.dod.internet.mgmt.mib-2.system có OID là 1.3.6.1.2.1.1, chứa tất
cả các object liên quan đến thông tin của một hệ thống như tên của thiết bị
(iso.org.dod.internet.mgmt.mib-2.system.sysName hay 1.3.6.1.2.1.1.5).
- Các OID của các hãng tự thiết kế nằm dưới tên định danh như sau:
iso.org.dod.internet.private.enterprise.
Ví dụ: Cisco nằm dưới iso.org.dod.internet.private.enterprise.cisco hay
1.3.6.1.4.1.9, Microsoft nằm dưới iso.org.dod.internet.private.enterprise.microsoft hay
1.3.6.1.4.1.311. Số 9 (Cisco) hay 311 (Microsoft) là số dành riêng cho các công ty do
IANA cấp 5. Nếu Cisco hay Microsoft chế tạo ra một thiết bị nào đó, thì thiết bị này có
thể hỗ trợ các MIB chuẩn đã được định nghĩa sẵn (như mib-2) hay hỗ trợ MIB được
thiết kế riêng. Các MIB được công ty nào thiết kế riêng thì phải nằm bên dưới OID của
công ty đó.
Các objectID trong MIB được sắp xếp thứ tự nhưng không phải là liên tục, khi
biết một OID thì không chắc chắn có thể xác định được OID tiếp theo trong MIB. VD
trong chuẩn mib-2 6 thì object ifSpecific và object atIfIndex nằm kề nhau nhưng OID
lần lượt là 1.3.6.1.2.1.2.2.1.22 và 1.3.6.1.2.1.3.1.1.1.

17


Muốn hiểu được một OID nào đó thì bạn cần có file MIB mô tả OID đó. Một
MIB file không nhất thiết phải chứa toàn bộ cây ở trên mà có thể chỉ chứa mô tả cho
một nhánh con. Bất cứ nhánh con nào và tất cả lá của nó đều có thể gọi là một mib.
Một manager có thể quản lý được một device chỉ khi ứng dụng SNMP manager
và ứng dụng SNMP agent cùng hỗ trợ một MIB. Các ứng dụng này cũng có thể hỗ trợ
cùng lúc nhiều MIB.

2.1.4. Mô hình giao thức SNMP
SNMP sử dụng các dịch vụ chuyển tải dữ liệu thông qua các giao thức UDP/IP.
Một ứng dụng của manager phải nhận dạng được agent cần thông tin với nó. Một ứng
dụng của agent được nhận dạng bởi địa chỉ IP của nó và một cổng UDP. Một ứng dụng
manager đóng gói yêu cầu SNMP trong một UDP/IP, UDP/IP chứa mã nhận dạng cổng
nguồn, địa chỉ IP đích và mã nhận dạng cổng UDP của nó. Khung UDP sẽ được gửi đi
thông qua thực thể IP tới hệ thống chịu sự quản lý, tại đó khung UDP sẽ được phân
phối bởi thực thể UDP tới agent. Tương tự, các bản tin TRAP phải được các manager
nhận dạng. Các bản tin sử dụng địa chỉ IP và mã nhận dạng cổng UDP của manager
SNMP. SNMP sử dụng 3 lệnh cơ bản là Read, Write, Trap và một số lệnh tùy biến để
quản lý thiết bị:
Lệnh Read: Được SNMP dùng để đọc thông tin từ thiết bị. Các thông tin này
được cung cấp qua các biến SNMP lưu trữ trên thiết bị và được thiết bị cập nhật.
Lệnh Write: Được SNMP dùng để ghi các thông tin điều khiển lên thiết bị bằng
cách thay đổi giá trị các biến SNMP.
Lệnh Trap: Dùng để nhận các sự kiện gửi từ thiết bị đến SNMP. Mỗi khi có một
sự kiện xảy ra trên thiết bị một lệnh Trap sẽ được gửi tới NMS.
SNMP điều khiển, theo dõi thiết bị bằng cách thay đổi hoặc thu thập thông tin
qua các biến giá trị lưu trên thiết bị. Các Agent cài đặt trên thiết bị tương tác với những
chip điều khiển hỗ trợ SNMP để lấy nội dung hoặc viết lại nội dung.
Giao thức SNMP sử dụng kiểu kết nối vô hướng (connectionless) để trao đổi
thông tin giữa các phần tử và hệ thống quản lý mạng (cụ thể là UDP - User Datagram
Protolcol - Giao thức dữ liệu đồ người sử dụng). UDP truyền các gói tin theo các khối
riêng biệt. Tuy vậy có thể tùy ý sử dụng các giao thức khác để truyền các gói tin
SNMP. Khi gửi các gói tin qua mạng, các phần tử mạng hay hệ thống quản lý mạng
vẫn giữ nguyên định dạng của SNMP.

18



Hình 2.11. Mô hình hoạt động giao thức SNMP

Ta thấy, SNMP thuộc về lớp ứng dụng trong mô hình giao thức, nó sử dụng UDP
làm giao thức lớp vận chuyển trên mạng IP.
Quản lý liên lạc giữa manager với các agent: Nhìn trên phương diện truyền
thông, manager và các agent cũng là những người sử dụng, sử dụng một giao thức ứng
dụng. Giao thức quản lý yêu cầu cơ chế vận chuyển để hỗ trợ tương tác giữa các agent
và manager. Manager trước hết phải xác định được các agent mà nó muốn liên lạc. Có
thể xác định được ứng dụng agent bằng địa chỉ IP của nó và cổng UDP được gán cho
nó. Cổng UDP 161 được dành riêng cho các agent SNMP. Manager gói lệnh SNMP
vào một tiêu đề UDP/IP. Tiêu đề này chứa cổng nguồn, địa chỉ IP đích và cổng 161.
Một thực thể IP tại chỗ sẽ chuyển giao gói UDP tới hệ thống bị quản lý. Tiếp đó, một
thực thể UDP tại chỗ sẽ chuyển phát nó tới các agent. Tương tự như vậy, lệnh TRAP
cũng cần xác định những manager mà nó cần liên hệ. Chúng sử dụng địa chỉ IP cũng
như cổng UDP dành cho SNMP manager, đó là cổng 162.

19


Hình 2.12. Vị trí của giao thức SNMP trong mô hình TCP/IP

Cơ chế vận chuyển thông tin giữa manager và agent: Việc lựa chọn cơ chế vận
chuyển là độc lập với giao thức truyền thông đó. SNMP chỉ đòi hỏi cơ chế vận chuyển
không tin cậy dữ liệu đồ (datagram) để truyền đưa các PDU (đơn vị dữ liệu giao thức)
giữa manager và các agent. Điều này cho phép sự ánh xạ của SNMP tới nhiều nhóm
giao thức. Mô hình vận chuyển datagram giảm được độ phức tạp của ánh xạ tầng vận
chuyển. Tuy nhiên, vẫn có một số lựa chọn cho tầng vận chuyển. Các tầng vận chuyển
khác nhau có thể sử dụng nhiều kĩ thuật đánh địa chỉ khác nhau. Các tầng vận chuyển
khác nhau có thể đưa ra những hạn chế quy mô của PDU. Ánh xạ tầng vận chuyển có
trách nhiệm phải xử lý các vấn đề đánh địa chỉ, hạn chế quy mô PDU và một số tham

số tầng vận chuyển khác. Trong phiên bản thứ hai của SNMP, người ta đã đơn giản hóa
quá trình ánh xạ tới các chuẩn vận chuyển khác nhau. Giao thức quản lý được tách
khỏi môi trường vận chuyển và điều này cũng được khuyến khích sử dụng cho bất cứ
nhóm giao thức nào.
Bảo vệ truyền thông liên lạc giữa manager và các agent khỏi sự cố: trong điều
kiện mạng thiếu ổn định và tin cậy thì việc truyền thông quản lý càng trở nên quan
trọng. Làm thế nào để các manager liên lạc với các agent một cách tin cậy? Việc
SNMP sử dụng cơ chế UDP để liên lạc đã làm thiếu đi độ tin cậy vì UDP hoạt động
theo kiểu dữ liệu đồ. SNMP để lại cho chương trình manager hoàn toàn chịu trách
nhiệm và xử lý việc mất thông tin. Các lệnh GET, GET-NEXT và SET đều được phúc
đáp bằng một lệnh GET-RESPONSE. Hệ thống có thể dễ dàng phát hiện ra việc bị mất
một lệnh khi không nhận được lệnh trả lời. Nó có thể lặp lại yêu cầu đó một lần nữa
hoặc có những hành động khác. Tuy nhiên, các bản tin TRAP do agent tạo ra lại không
yêu cầu phúc đáp. Khi bị thất lạc bản tin TRAP, các chương trình agent sẽ không biết
được điều đó (tất nhiên là manager cũng không hay biết về điều này). Thông thường
các bản tin TRAP mang những thông tin hết sức quan trọng cho manager, do vậy
manager cần chú ý và cần bảo đảm việc vận chuyển chúng một cách tin cậy. Một câu
hỏi đặt ra là làm thế nào để vận chuyển mà tránh được mất mát, thất lạc các bản tin
TRAP? Ta có thể thiết kế cho các agent gửi lặp lại bản tin TRAP. Biến số MIB có thể
20


đọc số lần lặp lại theo yêu cầu. Lệnh SET của manager có thể đặt cấu hình cho biến số
này. Có một cách khác là agent có thể lặp lại lệnh TRAP cho đến khi manager đặt biến
số MIB để chấm dứt sự cố. Tuy nhiên, cả hai phương pháp trên đều chỉ cho ta những
giải pháp từng phần. Trong trường hợp thứ nhất, số lần lặp lại có thể không đủ để đảm
bảo liên lạc một cách tin cậy. Trong trường hợp thứ hai, một sự cố mạng có thể dẫn
đến việc hàng loạt bản tin TRAP bị mất tùy thuộc vào tốc độ mà các agent tạo ra
chúng. Điều này làm cho sự cố mạng trở nên trầm trọng hơn. Trong cả hai trường hợp,
nếu ta cần chuyển những bản tin TRAP tới nhiều manager thì có thể xảy ra tình trạng

không nhất quán giữa các manager hoặc xảy ra hiện tượng thất lạc thông tin rất phức
tạp. Nếu các agent phải chịu trách nhiệm thiết kế cho việc phục hồi những bản tin
TRAP thì càng làm tăng thêm độ phức tạp trong việc quản lý các agent trong môi
trường đa nhà chế tạo. Người ta cũng đã cố gắng cải tiến cơ chế xử lý bản tin sự cố
cho phiên bản thứ hai của SNMP. Thứ nhất là đơn nguyên TRAP được bỏ đi và thay
thế nó bằng một lệnh GET/RESPONSE. Lệnh này do agent tạo ra và chuyển đến cho
“manager bẫy” tại cổng UDP-162. Điều này phản ánh quan điểm là bộ phận quản lý sự
cố có thể thống nhất các bản tin sự cố rồi trả lời cho các yêu cầu ảo. Bằng cách bỏ đi
một đơn thể, giao thức được đơn giản hóa. Người ta cũng bổ sung thêm một cơ sở
thông tin quản lí đặc biệt TRAP MIB để thống nhất việc xử lý sự cố, các manager nhận
bản tin về các sự cố này và việc lặp lại được thực hiện để cải thiện độ tin cậy trong
việc vận chuyển thông tin.
Ảnh hưởng của tầng vận chuyển tới khả năng quản lí mạng: việc sử dụng mạng
bị quản lý để hỗ trợ các nhu cầu thông tin liên lạc quản lý (quản lý trong băng) đã gây
ra nhiều vấn đề thú vị. Việc quản lý trong băng và ngoài băng độc lập với việc lựa
chọn giao thức quản lý. Quản lý trong băng có thể dẫn đến tình trạng mất liên lạc với
một agent đúng lúc agent đó cần sự chú ý về quản lý (tùy thuộc vào nguồn của sự cố).
Người ta có thể làm giảm nhẹ được vấn đề này nếu chính các thực thể mà agent quản
lý lại bảo vệ đường truy nhập tới các agent này. Có một ảnh hưởng nhỏ về khả năng
quản lý xuất hiện trong việc đánh địa chỉ tầng vận chuyển. Ví dụ: có thể xác định duy
nhất một agent SNMP bằng địa chỉ IP và số cổng UDP. Điều này có nghĩa là với một
địa chỉ IP cho trước thì ta chỉ có thể tiếp cận được một agent duy nhất. Hơn thế nữa
agent này lại chỉ duy trì một cơ sở thông tin quản lí MIB duy nhất. Do vậy, với một địa
chỉ IP duy nhất chỉ tồn tại một MIB. Việc gắn kết MIB với địa chỉ IP có thể hạn chế
được độ phức tạp của biến số liệu mà agent cung cấp. Xem xét trong cùng một hoàn
cảnh trong đó hệ thống yêu cầu nhiều MIB để quản lý các thành phần khác nhau của
nó. Cần phải thống nhất các MIB khác nhau này dưới một cây MIB tĩnh duy nhất để
có thể truy nhập chúng thông qua một agent duy nhất. Trong một số hoàn cảnh nhất
định, việc thống nhất đó không thể thực hiện được. Trong những trường hợp như vậy,
mỗi MIB đòi hỏi phải có riêng một nhóm giao thức SNMP/UDP/IP. Điều này làm tăng

phức tạp trong việc tổ chức quản lý (các thông tin tương quan từ nhiều MIB thuộc một
hệ thống cho trước) cũng như việc truy nhập nó (thông qua nhiều địa chỉ IP). Có một
cách khác là một agent duy nhất trong một hệ thống có thể giữ vai trò như một proxy
mở rộng cho các agent phụ đóng gói những cơ sở dữ liệu MIB khác nhau cùng liên
quan tới một phân hệ cho trước. Các phiên bản mở rộng SNMPv2 hỗ trợ phương pháp
này để xử lý nhu cầu truyền thông của manager. Các phiên bản mở rộng này cho phép
agent đóng vai trò như một manager của các agent con tại chỗ, do vậy cho phép tiếp
cận hàng loạt các agent con.
21


2.2. Các thành phần trong giao thức SNMP

Hình 2.13. Giao tiếp giữ Management và element

Kiến trúc của SNMP bao gồm 2 thành phần: các trạm quản lý mạng (Network
Management Station) và các thành tố mạng (Network Element).
Network management station là một máy tính chạy phần mềm quản lý SNMP
(SNMP management application), dùng để giám sát và điều khiển tập trung các
network element. Network element là các thiết bị, máy tính, hoặc phần mềm tương
thích SNMP và được quản lý bởi network management station. Như vậy element bao
gồm device, host và application. Một management station có thể quản lý nhiều
element, một element cũng có thể được quản lý bởi nhiều management station. Vậy
nếu một element được quản lý bởi 2 station thì điều gì sẽ xảy ra? Nếu station lấy thông
tin từ element thì cả 2 station sẽ có thông tin giống nhau. Nếu 2 station tác động đến
cùng một element thì element sẽ đáp ứng cả 2 tác động theo thứ tự cái nào đến trước.
Ngoài ra còn có khái niệm SNMP agent. SNMP agent là một tiến trình (process) chạy
trên network element, có nhiệm vụ cung cấp thông tin của element cho station, nhờ đó
station có thể quản lý được element. Chính xác hơn là application chạy trên station và
agent chạy trên element mới là 2 tiến trình SNMP trực tiếp liên hệ với nhau.

2.3. Cơ chế bảo mật của SNMP
Một SNMP management station có thể quản lý/giám sát nhiều SNMP element,
thông qua hoạt động gửi request và nhận trap. Tuy nhiên một SNMP element có thể
được cấu hình để chỉ cho phép các SNMP management station nào đó được phép quản
lý/giám sát mình.
Các cơ chế bảo mật đơn giản này gồm có : community string, view và SNMP
access control list.
2.3.1. Community String
Community string là một chuỗi ký tự được cài đặt giống nhau trên cả SNMP
manager và SNMP agent, đóng vai trò như “mật khẩu” giữa 2 bên khi trao đổi dữ liệu.
Community string có 3 loại: Read-community, Write-Community và Trap-Community.
Khi manager gửi GetRequest, GetNextRequest đến agent thì trong bản tin gửi đi
có chứa Read-Community. Khi agent nhận được bản tin request thì nó sẽ so sánh
22


Read-community do manager gửi và Read-community mà nó được cài đặt. Nếu 2
chuỗi này giống nhau, agent sẽ trả lời; nếu 2 chuỗi này khác nhau, agent sẽ không trả
lời.
- Write-Community được dùng trong bản tin SetRequest. Agent chỉ chấp nhận
thay đổi dữ liệu khi write-community 2 bên giống nhau.
- Trap-community nằm trong bản tin trap của trap sender gửi cho trap receiver.
Trap receiver chỉ nhận và lưu trữ bản tin trap chỉ khi trap-community 2 bên giống
nhau, tuy nhiên cũng có nhiều trap receiver được cấu hình nhận tất cả bản tin trap mà
không quan tâm đến trap-community.
2.3.2. - Community string có 3 loại như trên nhưng cùng một loại có thể
có nhiều string khác nhau. Nghĩa là một agent có thể khai báo nhiều readcommunity, nhiều write-community.
Trên hầu hết hệ thống, read-community mặc định là “public”, write-community
mặc định là “private” và trap-community mặc định là “public”.
Community string chỉ là chuỗi ký tự dạng cleartext, do đó hoàn toàn có thể bị

nghe lén khi truyền trên mạng. Hơn nữa, các community mặc định thường là “public”
và “private” nên nếu người quản trị không thay đổi thì chúng có thể dễ dàng bị dò ra.
Khi community string trong mạng bị lộ, một người dùng bình thường tại một máy tính
nào đó trong mạng có thể quản lý/giám sát toàn bộ các device có cùng community mà
không được sự cho phép của người quản trị.
2.3.3. View
Khi manager có read-community thì nó có thể đọc toàn bộ OID của agent. Tuy
nhiên agent có thể quy định chỉ cho phép đọc một số OID có liên quan nhau, tức là chỉ
đọc được một phần của MIB. Tập con của MIB này gọi là view, trên agent có thể định
nghĩa nhiều view. Ví dụ: agent có thể định nghĩa view, interfaceview bao gồm các OID
liên quan đến interface, storageView bao gồm các OID liên quan đến lưu trữ, hay
AllView bao gồm tất cả các OID.
Một view phải gắn liền với một community string. Tùy vào community string
nhận được là gì mà agent xử lý trên view tương ứng. Ví dụ: agent định nghĩa readcommunity “inf” trên view interfaceView, và “sto” trên storageView; khi manager gửi
request lấy OID ifNumber với community là “inf” thì sẽ được đáp ứng do ifNumber
nằm trong interfaceView; nếu manager request OID hrStorageSize với community
“inf” thì agent sẽ không trả lời do hrStorageSize không nằm trong interfaceView;
nhưng nếu manager request hrStorageSize với community “sto” thì sẽ được trả lời do
hrStorageSize nằm trong storageView.
Việc định nghĩa các view như thế nào tùy thuộc vào từng SNMP agent khác
nhau. Có nhiều hệ thống không hỗ trợ tính năng view.
2.3.4. SNMP access control list
Khi manager gửi không đúng community hoặc khi OID cần lấy lại không nằm
trong view cho phép thì agent sẽ không trả lời. Tuy nhiên khi community bị lộ thì một
manager nào đó vẫn request được thông tin.
Để ngăn chặn hoàn toàn các SNMP manager không được phép, người quản trị có
thể dùng đến SNMP access control list (ACL). SNMP ACL là một danh sách các địa
chỉ IP được phép quản lý/giám sát agent, nó chỉ áp dụng riêng cho giao thức SNMP và
23



được cài trên agent. Nếu một manager có IP không được phép trong ACL gửi request
thì agent sẽ không xử lý, dù request có community string là đúng.
Đa số các thiết bị tương thích SNMP đều cho phép thiết lập SNMP ACL.

24


Chương 3. CÀI ĐẶT VÀ THỰC HIỆN GIÁM SÁT MẠNG TRÊN PHẦN MỀM
3.1. Cài đặt giao thức SNMP
Để sử dụng phần mềm, trước tiên ta phải cấu hình SNMP trên windows.
Bước 1: Truy cập vào bảng Control Pannel -> Program and Features.

Hình 3.14. Control pannel

Tiếp theo, các bạn nhấn vào Turn Windows Features on or off -> Tích chọn
Simple Network Management Protocol (SNMP) -> OK.

Hình 3.15. Programs and Features

25


×