d) Thông báo lỗi của get, getnext, getbulk và set
2.1.4Truyền và nhận một Message SNMP
a) Truyền Message SNMP
Để truyền một trong năm dạng PDU cho một phần tử SNMP khác, phần tử SNMP phải thực hiện các hoạt động sau:
• Sử dụng ASN.1 để tạo ra PDU.
• PDU này được chuyển sang dịch vụ xác nhận cùng với các địa chỉ nguồn và đích của truyền thông và tên một truyền thông. Dịch vụ xác nhận thực hiện những biến đổi theo yêu cầu sau đó mã hoá hoặc thêm mã xác nhận và trả lại kết quả.
52 • Phần tử giao thức tạo ra một thông báo, thêm vào trường số hiệu phiên bản, tên
truyền thông vào kết quả của bước trên.
• Đối tượng ASN.1 mới này sau đó được mã hoá sử dụng BER và gửi đến dịch vụ giao vận.
b) Nhận Message SNMP
Khi nhận một thông báo từ một phần tử SNMP khác, một phần tử SNMP phải
thực hiện các hoạt động sau:
• Kiểm tra cú pháp cơ bản của thông báo và loại bỏ thông báo nếu cú pháp sai • Kiểm tra số hiệu phiên bản và loại bỏ thông báo nếu không tương hợp.
Trong SNMP, chỉ có các đối tượng “lá” trong cây nhận dạng đối tượng, các đối tượng vô hướng là có thể truy cập. Tuy nhiên SNMP có khả năng nhóm các toán tử cùng dạng (get, set, trap) vào một thông báo, do vậy nếu một trạm quản trị muốn nhận các giá trị của tất cả các đối tượng trong một nhóm nhất định tại một Agent nhất định, nó có thể dùng một thông báo đơn, yêu cầu tất cả các giá trị và nhận lại một đáp ứng đơn các liệt kê tất cả các giá trị. Kỹ thuật này có thể làm giảm rất nhiều tải trọng truyền thông của quản trị mạng. Để thực hiện điều đó, các PDU của SNMP đều có trường
variable-bindings (mục 2.1.1.4/b). Trường này bao gồm một thứ tự các tham chiếu đến các phiên bản đối tượng cùng với giá trị của các đối tượng đó.
c) GetRequest PDU
Một phần tử SNMP đưa ra GetRequestPDU thay mặt cho một ứng dụng trạm quản trị. Phần tử bao gồm các trường hợp sau trong PDU:
• Dạng PDU: thể hiện một GetRequestPDU.
• Request-id: phần tử gửi gán các số như vậy để người dùng mỗi yêu cầu gửi đi đến cùng một Agent là xác định duy nhất. Nó cho phép ứng dụng SNMP liên kết các đáp ứng truyền đến với yêu cầu còn lại, và cũng cho phép một phần SNMP loại bỏ các PDU kép được sinh ra do dịch vụ giao vận không tin cậy.
• Variable bindings (các liên kết biến): liệt kê các phiên bản đối tượng có giá trị được yêu cầu.
Phần tử SNMP nhận đáp ứng một GetRequestPDU bằng một GetResponsePDU có chứa cùng một request-id. Toán tử GetRequest có tính hạt nhân: hoặc lấy được tất
53 cả các giá trị hoặc không lấy bất cứ giá trị nào. Nếu phần tử đáp ứng có khả năng cung cấp tất cả các giá trị của các biến được liệt kê trong danh sách biến liên kết, thì GetResponsePDU bao gồm trường các liên kết biến với giá trị được cấp cho mỗi biến. Nếu ít nhất một biến không thể cấp giá trị thì sẽ không có giá trị nào được trả về. Các điều khiển sau có thể xảy ra:
• Một đối tượng được đặt tên trong danh sách biến có thể không phù hợp với bất kỳ nhận dạng đối tượng nào trong MIB tương ứng, hoặc trên đối tượng là một dạng gộp mà không có giá trị phiên bản tương ứng. Trong trường hợp khác, phần tử đáp ứng trả về một GetResponsePDU có một error-status là noSuchName và một giá trị trong trường error-index là thứ tự của đối tượng bị lỗi trong trường liên kết biến.
• Phần tử đáp ứng có khả năng cấp các giá trị cho tất cả các biến trong danh sách nhưng kích thước của GetResponsePDU có thể vượt quá một giới hạn cục bộ. Trong trường hợp này, phần tử đáp ứng trả về một GetResponsePDU có error- status là toobig.
• Phần tử đáp ứng có thể không có khả năng cung cấp một giá trị cho ít nhất một trong các đối tượng vì một vài nguyên nhân. Khi đó phần tử đáp ứng trả về một GetRequestPDU với một lỗi error-status là getErr và một giá trị trong trường error-index là thứ tự của đối tượng vị lỗi trong trường liên kết biến.
d) GetNextRequestPDU
GetNextRequestPDU hầu như giống với GetRequestPDU cả về hình thức PDU lẫn dạng. Chỉ khác nhau như sau: trong GetRequestPDU,mỗi biến trong danh sách biến liên kết tham chiếu đến một phiên bản đối tượng cần trả giá trị còn trong GetNextRequestPDU,với một biến, việc đáp ứng sẽ trả về một giá trị của một phiên bản đối tượng mà là tiếp theo trong trật tự thứ tự (chú ý rằng đây là phiên bản đối tượng tiếp theo chứ không phải đối tượng tiếp theo). Điều này cho phép một trạm quản trị mạng khảo sát cấu trúc của một MIB theo cách động là một cơ chế có hiệu quả trong việc tìm kiếm trong một bảng mà có tất cả các mục là không biết.
Gọi một giá trị đối tượng đơn: Khi một trạm quản trị mạng muốn nhận các giá trị của tất cả các đối tượng từ một Agent, nó có thể gửi một GetRequestPDU với một
54 danh sách biến liên kết. Tuy nhiên nếu có bất cứ một đối tượng nào trong danh sách đó không thể trả về một GetResponsePDU được trả về với một thống kê lỗi là noSuchname. Như vậy để chắc chắn nhận được tất cả cá giá trị có thể với GetRequestPDU,trạm quản trị mạng phải gửi lần lượt các GetRequestPDU cho mỗi giá trị biến cần thiết. Trong khi đó, GetResponsePDU sẽ trả về các giá trị phiên bản đối tượng sẵn có và với các giá trị phiên bản đối tượng không có sẵn, giá trị phiên bản đối tượng tiếp theo trong trật tự sẽ được trả về. Rõ ràng đây là cách có hiệu quả hơn để gọi mọi tập các giá trị đối tượng khi có thể có có thất lạc so với sử dụng GetRequestPDU.
Gọi các đối tượng không biết: GetNextRequestPDU yêu cầu Agent gọi phiên bản đối tượng tiếp theo xuất hiện theo thứ tự sau nhận dạng đã đưa ra mà không yêu cầu cung cấp nhận dạng của một đối tượng hay phiên bản đối tượng thực. Do vậy một trạm quản trị mạng có thể sử dụng GetNextRequestPDU để thăm dò một MIB và khám phá cấu trúc của nó.
Truy cập các giá trị bảng: GetNextRequestPDU là một cách để tìm kiếm một bảng khi nó không biết nội dung của bảng thậm chí không biết cả số hàng trong bảng. Nó sẽ gửi về các GetNextRequestPDU cho đến khi GetResponsePDU của Agent trả về chứa các tên đối tượng không phù hợp với yêu cầu.
e) SetRequestPDU
SetRequestPDU giống với GetRequestPDU cả về hình thức PDU lẫn dạng, tuy nhiên SetRequestPDU dùng để ghi (thay đổi) thông tin, thuộc tính một đối tượng hơn là đọc giá trị. Do vậy danh sách biến liên kết trong SetRequestPDU bao gồm các nhận dạng phiên bản đối tượng và một giá trị sẽ được gán cho mỗi phiên bản đối tượng trong danh sách. Phần tử SNMP nhận đáp ứng một SetRequestPDU bằng một GetRequestPDU có chứa cùng một request-id. Toán tử SetRequest có tính hạt nhân: hoặc tất cả các giá trị biến được cập nhập hoặc không có giá trị nào cả. Nếu phần tử đáp ứng có khả năng gán tất cả các giá trị của các biến được liệt kê trong danh sách biến liên kết được gửi đến, thì GetResponsePDU bao gồm trường các liên kết biến với giá trị đã gán cho mỗi biến. Nếu có ít nhất một biến không thể gán giá trị thì sẽ không có giá trị nào được gán, các điều kiện lỗi tương tự như trong trường hợp GetRequestPDU sẽ được trả về hoặc với điều kiện lỗi khác: badValue (xảy ra khi có ít (adsbygoogle = window.adsbygoogle || []).push({});
55 nhất một cặp tên biến và giá trị không tương thích nhau để có thể về dạng, độ dài hoặc giá trị thực của giá trị được cung cấp).
f) Trap PDU
Trap PDU sử dụng để cung cấp cho trạm quản trị một thông báo về một vài sự kiện quan trọng. Khi NMS nhận một trap, nó cần biết phải làm gì để hiểu nội dung thông tin kèm theo thông báo trap này, một trap đầu tiên được nhận xác định thông qua các số ở đây có 7 số cơ bản (xem bảng 2.3), sử dụng enterprises để xác định các nhánh cây của từng hãng cụ thể, ví dụ Cisco định nghĩa tất cả các trap trong cây MIB của riêng hãng theo cấu trúc sau iso.org.dod.internet.private.enterprises.cisco. các số trap này phải được đăng ký với IANA (Internet Assigned Numbers Authority).
Ví dụ khi một modem trong trủ rack bị hỏng, rack agent có thể gửi thông tin trap thông báo hỏng cho NMS, với thông tin trap gửi đến ta xác định được rack đó là của hãng nào, và biết được chính xác modem nào bị hỏng trong số các modem khác trong tủ rack…
Tên và số của trap Mô tả
coldStart (0) Thông báo agent vừa khởi động lại. Tất cả các biến quản lý sẽ được reset, các biến kiểu “Counters” và “Gauges” được đặt về 0. “coldStart” dùng để xác định một thiết bị mới gia nhập vào mạng. Khi một thiết bị khởi động xong, nó gửi một “trap” tới NMS. Nếu địa chỉ NMS là đúng (địa chỉ IP của NMS), NMS có thể nhận được và xác định xem có quản lý thiết bịđó hay không. warmStart (1) Thông báo agent vừa khởi tạo lại, không có biến nào bị reset. linkDown (2) Gửi đi khi một interface trên thiết bị chuyển sang trạng thái
“down”. Giá trị biến đầu tiên trong bảng interface sẽđược gửi đi. linkUp (3) Gửi đi khi một interface trở lại trạng thái “up”. Giá trị biến
binding của interface sẽđược thiết lập lại.
authenticationFailure (4) Cảnh báo khi một người nào đó cố truy cập vào agent đó mà không được xác thực
egpNeighborLoss (5) Cảnh báo một EGP lân cận bị “down”
enterpriseSpecific (6) Đây là một “trap” riêng, chỉ được biết bởi agent và NMS tự định nghĩa riêng chúng. NMS sử dụng phương pháp giải mã đặc biệt để
hiểu được thông điệp này.
Bảng 2.3 Mô tả tên và số của Trap
RDBMS MIB định nghĩa trong RFC 1697. Một trap được định nghĩa bởi MIB rdbmsOutOfSpace:
56 rdbmsOutOfSpace TRAP-TYPE
ENTERPRISE rdbmsTraps
VARIABLES { rdbmsSrvInfoDiskOutOfSpaces } DESCRIPTION
"An rdbmsOutOfSpace trap signifies that one of the database servers managed by this agent has been unable to allocate space for one of the databases managed by this agent. Care should be taken to avoid flooding the network with these traps."
::= 2
Tên enterprise là rdbmsTraps và số là 2. Trap này có một biến binding là rdbmsSrvInfoDiskOutOfSpaces, đây là một biến vô hướng của MIB. Nó được định nghĩa như sau :
rdbmsSrvInfoDiskOutOfSpaces OBJECT-TYPE SYNTAX Counter
ACCESS read-only STATUS mandatory DESCRIPTION
"The total number of times the server has been unable to obtain disk space that it wanted, since server startup. This would be inspected by an agent on receipt of an rdbmsOutOfSpace trap."
::= { rdbmsSrvInfoEntry 9 }
2.2 Quản trị mạng với giao thức SNMPV2
SNMP trước đây phát triển như là một cách lấp chỗ trống để cung cấp khả năng quản trị mạng thấp nhất. SNMP có hai ưu điểm chính:
1. Cấu trúc thông tin quản trị (SMI) và cơ sở thông tin quản trị (MIB) của nó khá đơn giản vì vậy có thể dễ dàng và nhanh chóng thực hiện.
2. SNMP dựa trên cơ sở giao thức kiểm soát cổng đơn giản (SNMP), với một số khối lượng lớn các kinh nghiệm thu được.
Từ năm 1988, việc quản trị mạng đã trở nên rất cần thiết cả đối với độ phức tạp của mạng và các môi trường phức tạp hơn. Tuy nhiên, SNMP chưa cung cấp các phương tiện an toàn và khả năng xác nhận nguồn của một thông báo quản trị hoặc chống lại việc nghe trộm. Mặt khác, việc tồn tại tên truyền thông trong phần đầu thông báo cũng là điểm yếu trên quan điểm an toàn. Do vậy nhiều nhà sản xuất đã không cho
57 thực hiện lệnh set trên thiết bị của mình. Để giải quyết vấn đề này, tháng 7-1992 phần “an toàn SNMP” bắt đầu được đưa ra và định nghĩa một SNMP tiêu chuẩn mới là SNMPv2 và từ tháng 10-1992, SNMPv2 được phát triển cho đến tháng 3-1993. Đến năm 1996, những sản phẩm an toàn trong SNMPv2 bị bỏ qua trong khi các phần khác chỉ là sự thay đổi mới hơn và SNMPv2 được gọi là “SNMPv2 trên cơ sở truyền thông” hay SNMPv2C. (adsbygoogle = window.adsbygoogle || []).push({});
SNMPv2 có thể hỗ trợ các mạng trung tâm cấp cao hoặc các mạng phân tán. Những điểm nâng cấp chính của SNMP được đưa ra trong SNMPv2 nằm trong các vùng sau:
1. Cấu trúc thông tin quản trị (SMI): SNMPv2 mở rộng SNMPV1 SMI theo một vài cách. Bổ sung thêm các đối tượng mới bằng cách sử dụng Macro để định nghĩa các dạng đối tượng và nâng cấp thông tin liên quan đến một đối tượng. nó cung cấp một quy ước mới để thêm hoặc xoá các hàng trong bảng.
2. Khả năng trao đổi giữa các trạm quản trị: bổ sung InformRequestPDU
cho phép một trạm quản trị gửi một thông báo dạng Trap cho một trạm quản trị khác.
Các hoạt động giao thức SNMPv2 MIB chứa thông tin lưu chuyển cơ bản về hoạt động của giao thức SNMPv2, và chứa thông tin liên quan đến cấu hình của Agent hoặc trạm quản trị SNMPv2 và có thêm PDU mới: GetBulkRequestPDU cho phép trạm quản trị nhận các khối dữ liệu lớn một cách có hiệu quả.
2.2.1 SMI trong SNMPV2
SMIv2 mở rộng cây đối tượng SMI bằng cách thêm snmpV2 làm cây con của internet (xem hình 2.13) và OID của cây mới này là 1.3.6.1.6.3.1.1 hoặc iso.org.dod.internet.snmpV2.snmpModules.snmpMIB.snmpMIBObjects. Các kiểu dữ liệu mới của SMIv2 được mô tả chi tiết trong bảng 2.4 sau:
Kiểu dữ liệu Mô tả
Integer32 Giống như INTEGER. Counter32 Giống như Counter.
58
Kiểu dữ liệu Mô tả
Gauge32 Giống như Gauge.
Unsigned32 Số thập phân từ 0 tới 232 - 1
Counter64 Giống Counter32, nhưng giá trị lớn nhất là 18,446,744,073,709,551,615. Có thể trở về giá trị 0 trong khoảng thời gian ngắn
BITS Tên bộđếm số bít
Bảng 2.4 Kiểu dữ liệu mới của SMIv2
Hình 2.13 Cây SMIv2
Định nghĩa một đối tượng trong SMIv2 không khác nhiều so với SMIv1, ở đây có thêm một số trường tùy chọn, cho phép ta điều khiển cách truy xuất (truy cập ) một đối tượng, cho phép thêm các cột vào bảng và giúp bạn mô tả đầy đủ hơn về đối tượng,
59 dưới đây cú pháp của đối tượng được định nghĩa trong SMIv2, sự thay đổi được in đậm (bảng 2.5):
<name> OBJECT-TYPE SYNTAX <datatype>
UnitsParts <Optional, see below>
MAX-ACCESS <See below>
STATUS <See below>
DESCRIPTION
"Textual description describing this particular managed object."
AUGMENTS { <name of table> }
::= { <Unique OID that defines this object> }
Các đối tượng Mô tả
UnitsParts Mô tả về các đơn vị (ví dụ như giây, phần nghìn giây,...) sử dụng cho
đối tượng. (adsbygoogle = window.adsbygoogle || []).push({});
MAX-ACCESS Giá trị của tùy chọn MAX-ACCESS là read-only, read-write, read- create, not-accessible, và accessible-for-notify.
STATUS Sử dụng giống như trong SNMPv1 MIB.
AUGMENTS Trong một số trường hợp nó hữu ích khi thêm cột vào bảng đã có, sử
dụng AUGMENTS để mở rộng bảng bằng cách thêm một hay nhiều cột
đại diện cho một số đối tượng khác và dẫn đến tên của bảng đối tượng sẽ tăng thêm.
Bảng 2.5 Các đối tượng thay đổi trong SNMPv2 so với SNMPv1
a) get-bulk
getbulk được định nghĩa trong SNMPv2. Nó cho phép lấy thông tin quản lý từ nhiều phần trong bảng. Dùng ”get” có thể làm được điều này. Tuy nhiên, kích thước của câu hỏi có thể bị giới hạn bởi agent. Khi đó nếu nó không thể trả lời toàn bộ yêu cầu, nó gửi trả một thông điệp lỗi mà không có dữ liệu. Với trường hợp dùng câu lệnh ”getbulk”, agent sẽ gửi càng nhiều trả lời nếu nó có thể. Do đó, việc trả lời một phần của yêu cầu là có thể xảy ra. Hai trường cần khai báo trong “getbulk” là: ”nonrepeaters” và ”max-repetitions”. Nonrepeaters báo cho agent biết N đối tượng đầu tiên có thể trả lời lại như một câu lệnh ”get” đơn mã, repeaters báo cho agent biết cần cố gắng tăng lên tối đa M yêu cầu ”getnext” cho các đối tượng còn lại:
60 Để chuẩn hóa định dạng PDU trap của SNMPv1 do PDU của get và set khác nhau, SNMPv2 định nghĩa NOTIFICATION-TYPE, định dạng PDU của NOTIFICATION-TYPE là để nhận ra get và set. NOTIFICATION-TYPE được định nghĩa trong RFC 2863:
linkDown NOTIFICATION-TYPE
OBJECTS { ifIndex, ifAdminStatus, ifOperStatus } STATUS current
DESCRIPTION
"A linkDown trap signifies that the SNMPv2 entity, acting in an agent role, has detected that the ifOperStatus object for one of its communication links left the down state and