NetL2-ATM (Asynchronous Transfer Mode)

NetL2 - Fiber Distributed Data Interface (FDDI)

NetL2 - STP

NetL2 - Token Ring

NetL2 - Frame Relay

NetL2 - STP,RSTP,PVST,MSTP (Spanning Tree Protocol,...)

NetL2-HDLC (High-Level Data Link Control) and PPP (Point to Point)

2. HDLC Protocol Description

HDLC [High-level Data Link Control] là một bộ giao thức dùng để truyền nhận đồng bộ các gói tin trên các tuyến kết nối point-to-point. HDLC đóng dữ liệu thành các frames. HDLC hoạt động ở layer 2 của mô hình OSI - Data Link layer.

General HDLC Frame

General HDLC Frame

Opening Flag, 8 bits [01111110], [7E hex]
Address, 8 bits [ could be more]
Control, 8 bits, or 16 bits
Data [Payload], Thay đổi, có thể không dùng trong một số frame
CRC, 16 bits, or 32 bits
Closing Flag, 8 bits [01111110], [7E hex]

User data which contains 7E is resolved using an escape sequence which converts 7E to 7D-5E [with 7D being the escape character]. If 7D is used in the data stream it again is converted into 7D-5D. Address 11111111 is known as all stations, 00000000 is this station.

Frames may be aborted by sending an abort sequence [01111111] instead of the normal flag sequence [01111110]. An abort sequence will cause the frame to be discarded. During idle times when no frames are being transmitted idle flags [11111111] may be sent to fill the area between frames. A continuous series of flags [01111110] may be sent to fill the area between frames instead of sending idle flags [11111111].

Fill between Frames

HDLC Opening Flag
8 bits [01111110], [7E hex]
The Opening flag may be preceded by additional flags [01111110] or idle flags [11111111], both used as inter-frame fill.

HDLC Address Field

HDLC Address Field
The length of the address field depends on the data link layer protocol used, but is normally 0, 8 or 16 bits in length. In many cases the address field is typically just a single byte, but an Extended Address [EA] bit may be used allowing for multi-byte addresses. A one residing in the LSB bit indicates [the end of the field] that the length of the address field will be 8 bits long. A zero in this bit location [now the first byte of a multi-byte field] indicates the continuation of the field [adding 8 additional bits]. The SDLC protocol will use only an 8 bit address. The SS7 protocol, which is used in point-to-point links, does not use an address field at all.

The first [MSB] bit in the Address field indicates if the frame is a unicast or multi-cast message. A zero in the MSB bit location indicates a unicast message; the remaining bits indicate the destination node address. A one in the MSB bit location indicates multicast message, the remaining bits indicate the group address.


HDLC Control Field
The Control field is 8 or 16 bits and defines the frame type; Control or Data. The Control field is protocol dependent.

HDLC Data Field
The Data field may vary in length depending upon the protocol using the frame. Layer 3 frames are carried in the data field.

HDLC FCS Field
FCS [16 bits] = X¹⁶ + X¹² + X⁵ + 1
FCS [32 bits] = X³² + X²⁶ + X²³ + X²² + X¹⁶ + X¹² + X¹¹ + X¹⁰ + X⁸ + X⁷ + X⁵ + X⁴ + X² + X + 1

Frame Encapsulation:
A few different versions of the HDLC frame are shown below. These include the PPP [Point-to-Point Protocol] HDLC frame, and the Ethernet HDLC frame.

Ethernet HDLC Frame Encapsulation

Ethernet Frame Encapsulation:
The Preamble [a specific bit pattern] Informs the receiving station that a new packet is arriving and synchronizes the receive clock with the transmitted clock. Used in Ethernet, not HDLC.

The Address Field consists of a Source Address and/or a Destination Address. The Source and Destination Addresses identify the sender [Source] and receiver [Destination]. The Source Address is used to identify to the network that's sending data. The Destination Address is used to identify who should be receiving the data. Some protocols may only have one address.

The Control Field indicates the type of Information that is being sent as Data. It identifies the purpose of the packet as Data or Control information, and may also indicate the size of the packet and Data.

The Data Field is the actual information being transmitted. It can contain Control Information for handshaking, or actual Data used by applications.

The CRC [Cyclic Redundancy Checking] or FCS [Frame Check Sequence] contains an error checking number that the Destination can use to verify that the packet is error free.

The End Frame Delimiter has a specific bit pattern. This bit pattern identifies the end of the packet to the Destination. Protocols with fixed packet size may not require an End Frame Delimiter.

For some physical interfaces [SDH or SONET] after the data as been encapsulated into the frame it must still be scrambled before being sent to the physical layer [from the Link layer].

Point-to-Point Protocol HDLC Frame Encapsulation

Point-to-Point Protocol Frame Encapsulation:
Point-to-Point Protocol [PPP] is used in transporting multi-protocol datagrams over point-to-point links. PPP is capable of operating on many DTE/DCE interfaces (such as, RS-232C, RS-422, RS-423 or V.35). PPP is used with full-duplex circuits [dedicated or circuit-switched] operating in either an asynchronous (start/stop), bit-synchronous, or octet-synchronous mode, transparent to PPP Data Link Layer frames. PPP does not require the use of control signals, such as Request To Send (RTS), Clear To Send (CTS), Data Carrier Detect (DCD), and Data Terminal Ready (DTR). For asynchronous links, inter-octet and inter-frame time fill MUST be accomplished by transmitting continuous "1" bits.

---

HDLC IC Manufacturers

HDLC: High-Level Data Link Control.
SDLC: Synchronous Data Link Control. Link layer protocol based on synchronous, bit-oriented operation. Other Protocols; LAP; Link Access Procedure and LAPB; Link Access Procedure, Balanced, PPP Point-to-Point Protocol and Frame Relay.

2. Point to Point Protocol

PPPlà một bộ giao thức layer 2 thường dùng để thiết lập các kết nối trực tiếp giữa hai node mạng thông qua các đường kết nối như serial cable, line điện thoại, đường trunk, sóng radio hay các tuyến kết nối cáp quang. Hầu hết các nhà cung cấp dịch vụ internet sử dụng PPP giúp khách hàng tạo kết nối dial-up đến ISP để truy cập internet. Hai hình thức đóng gói thường gặp nhất của PPP là Point-to-Point Protocol over Ethernet (PPPoE) và Point-to-Point Protocol over ATM(PPPoA) và chúng thường được sử dụng với các công nghệ Digital Subscriber Line (DSL).

PPP còn được dùng như là giao thức layer 2 cho các kết nối mạch đồng bộ và bất đồng bộ như Serial Line Internet Protocol (SLIP),Link Access Protocol, Balanced (LAPB). PPP được thiết kế để làm việc với nhiều giao thức layer 3 như Internet Protocol (IP), Internetwork Packet Exchange (IPX), NBF và AppleTalk.
PPP được mô tả trong RFC 1661.

Xem thêm các giao thức trong bộ giao thức PPP

2.1 PPP General Frame Format

All messages sent using PPP can be considered either data or control information. The word “data” describes the higher-layer datagrams we are trying to transport here at layer two; this is what our “customers” are giving us to send. Control information is used to manage the operation of the various protocols within PPP itself. Even though different protocols in the PPP suite use many types of frames, at the highest level they all fit into a single, general frame format.

In the overview of PPP I mentioned that the basic operation of the suite is based on the ISO High-Level Data Link Control (HDLC) protocol. This becomes very apparent when we look at the structure of PPP frames overall—they use the same basic format as HDLC, even to the point of including certain fields that aren't strictly necessary for PPP itself. The only major change is the addition of a new field to specify the protocol of the encapsulated data. The general structure of PPP frames is defined in RFC 1662, a “companion” to the main PPP standard RFC 1661.

The general frame format for PPP, showing how the HDLC framing is applied to PPP, is described in Table 32 and illustrated in Figure 32.

Table 32: PPP General Frame Format

Field Name	Size (bytes)	Description
Flag	1	Flag: Indicates the start of a PPP frame. Always has the value “01111110” binary (0x7E hexadecimal, or 126 decimal).
Address	1	Address: In HDLC this is the address of the destination of the frame. But in PPP we are dealing with a direct link between two devices, so this field has no real meaning. It is thus always set to “11111111” (0xFF or 255 decimal), which is equivalent to a broadcast (it means “all stations”).
Control	1	Control: This field is used in HDLC for various control purposes, but in PPP it is set to “00000011” (3 decimal).
Protocol	2	Protocol: Identifies the protocol of the datagram encapsulated in the Information field of the frame. See below for more information on the Protocol field.
Information	Variable	Information: Zero or more bytes of payload that contains either data or control information, depending on the frame type. For regular PPP data frames the network-layer datagram is encapsulated here. For control frames, the control information fields are placed here instead.
Padding	Variable	Padding: In some cases, additional dummy bytes may be added to pad out the size of the PPP frame.
FCS	2 (or 4)	Frame Check Sequence (FCS): A checksum computed over the frame to provide basic protection against errors in transmission. This is a CRC code similar to the one used for other layer two protocol error protection schemes such as the one used in Ethernet. It can be either 16 bits or 32 bits in size (default is 16 bits). The FCS is calculated over the Address, Control, Protocol, Information and Padding fields.
Flag	1	Flag: Indicates the end of a PPP frame. Always has the value “01111110” binary (0x7E hexadecimal, or 126 decimal).

Figure 32: PPP General Frame Format

All PPP frames are built upon the general format shown above. The first three bytes are fixed in value, followed by a two-byte Protocol field that indicates the frame type. The variable-lengthInformation field is formatted in a variety of ways, depending on the PPP frame type. Padding may be applied to the frame, which concludes with an FCS field of either 2 or 4 bytes (2 bytes shown here) and a trailing Flag value of 0x7E. See Figure 33 for an example of how this format is applied

Figures 33 shows one common application of the PPP general frame format: carrying data.The value 0x0021 in the Protocol field marks this as an IPv4 datagram. This sample has one byte of Padding and a 2-byte FCS as well. (Obviously real IP datagrams are longer than the 23 bytes shown here! These bytes are arbitrary and don’t represent a real datagram.) See Figure 43 for an illustration of how this same data frame is formatted and then fragmented for transmission over multiple links using the PPP Multilink Protocol.

Figure 33: Sample PPP Data Frame

This sample PPP data frame has a value of 0x0021 in the Protocol field, indicating it is an IP datagram (though the actual data is made up and not a real IP message.)

Protocol Field Ranges

The Protocol field is the main “frame type” indicator for the device receiving the frame. For data frames this is normally the network-layer protocol that created the datagram, and for control frames, the PPP protocol that created the control message. In the case of protocols that modify data such as whencompression (CCP) or encryption (ECP) are used, this field identifies the data as being either compressed or encrypted, and the original Protocol value is extracted after the Information field is decompressed/decrypted.

There are dozens of network-layer protocols and PPP control protocols, and a correspondingly large number of Protocol values The main PPP standard defines four ranges for organizing these values, as shown in Table 33.

Table 33: PPP Protocol Field Ranges

Protocol Field Range (hexadecimal)	Description
0000 - 3FFF	Encapsulated network layer datagrams that have an associated Network Control Protocol (NCP). In this case, control frames from the corresponding NCP use a Protocol field value that is computed by adding “8” to the first octet of the network layer Protocol value. For example, for IP the Protocol value is 0021, and control frames from the IP Control Protocol (IPCP) use Protocol value 8021. This range also includes several values used for specially-processed encapsulated datagrams, such as when compression or encryption are employed.
4000 - 7FFF	Encapsulated datagrams from “low-volume” protocols. These are protocols that do not have an associated NCP.
8000 - BFFF	Network Control Protocol (NCP) control frames that correspond to the network layer Protocol values in the 0000-3FFF range.
C000 - FFFF	Control frames used by LCP and LCP support protocols such as PAP and CHAP. Some miscellaneous protocol values are included here as well.

The standard also specifies that the Protocol value must be assigned so that the first octet is even, and the second octet is odd. So, for example, 0x0021 is a valid value but 0x0121 and 0x0120 are not. (The reason for this will become apparent shortly). There are also certain blocks that are reserved and not used.

Protocol Field Values

The full list of PPP Protocol values is maintained by the Internet Assigned Numbers Authority (IANA) along with all the other different reserved numbers for Internet standards. Table 34 shows some of the more common values:

Table 34: Common Protocols Carried In PPP Frames and Protocol Field Values

Protocol Type	Protocol Field Value (hex)	Protocol
Encapsulated Network Layer Datagrams	0021	Internet Protocol version 4 (IPv4)
	0023	OSI Network Layer
	0029	Appletalk
	002B	Novell Internetworking Packet Exchange (IPX)
	003D	PPP Multilink Protocol (MP) Fragment
	003F	NetBIOS Frames (NBF/NetBEUI)
	004D	IBM Systems Network Architecture (SNA)
	0053	Encrypted Data (using ECP and a PPP encryption algorithm)
	0055	Individual-Link Encrypted Data under PPP Multilink
	0057	Internet Protocol version 6 (IPv6)
	00FB	Individual-Link Compressed Data under PPP Multilink
	00FD	Compressed Data (using CCP and a PPP compression algorithm)
Low-Volume Encapsulated Protocols	4003	CDPD Mobile Network Registration Protocol
	4025	Fibre Channel
Network Control Protocol (NCP) Control Frames	8021	PPP Internet Protocol Control Protocol
	8023	PPP OSI Network Layer Control Protocol
	8029	PPP Appletalk Control Protocol
	802B	PPP IPX Control Protocol
	803F	PPP NetBIOS Frames Control Protocol
	804D	PPP SNA Control Protocol
	8057	PPP IPv6 Control Protocol
LCP and Other Control Frames	C021	PPP Link Control Protocol (LCP)
	C023	PPP Password Authentication Protocol (PAP)
	C025	PPP Link Quality Report (LQR)
	C02B	PPP Bandwidth Allocation Control Protocol (BACP)
	C02D	PPP Bandwidth Allocation Protocol (BAP)
	C223	PPP Challenge Handshake Authentication Protocol (CHAP)

PPP Field Compression

PPP uses the HDLC basic framing structure, which includes two fields that are needed in HDLC but not in PPP due to how the latter operates: the Addressand Control fields. Why bother sending two bytes that have the same value for every frame and aren't used for anything? Originally they were maintained for compatibility, but this reduces efficiency.

To avoid wasting two bytes in every frame, it is possible during initial link setup using LCP for the two devices on the link to negotiate a feature calledAddress and Control Field Compression (ACFC) using the LCP option by that same name. When enabled, this feature simply causes these two fields not to be sent for most PPP frames (but not LCP control frames.) In fact, the feature would be better named “Address and Control Field Suppression” because the fields are just suppressed: compressed down to nothing.

Now, even when devices agree to use field compression, they must still be capable of receiving both “compressed” and “uncompressed” frames. They differentiate one from the other by looking at the first two bytes after the initial Flag field. If they contain the value 0xFF03, they must be the Address andControl fields; otherwise, those fields were suppressed. (The value 0xFF03 is not a valid Protocol field value, so there is no chance of ambiguity.)

Similarly, it is also possible for the two devices on the link to negotiate compression of the Protocol field, so it takes only one byte instead of two. This is done generally by dropping the first byte if it is zero, a process called Protocol Field Compression (PFC). Recall that the first byte must be even and the second odd. Thus, a receiving device examines the evenness of the first byte of the Protocol field in each frame. If it is odd, this means that a leading byte of zeroes in the Protocol field has been suppressed, because the first byte of a full two-byte Protocol value must be even.

NetL2-CDP ( Cisco Discovery Protocol)

NetL2-Ethernet

NetML - Giao thức SNMP

I. SNMP:
1. Giới thiệu – Các khái niệm:

Cốt lõi của SNMP là một tập hợp đơn giản các hoạt động giúp nhà quản trị mạng có thể quản lý, thay đổi trạng thái của mạng. Ví dụ chúng ta có thể dùng SNMP để tắt một interface nào đó trên router của mình, theo dõi hoạt động của card Ethernet, hoặc kiểm soát nhiệt độ trên switch và cảnh báo khi nhiệt độ quá cao.
SNMP thường tích hợp vào trong router, nhưng khác với SGMP( Simple Gateway Management Protocol) được dùng chủ yếu cho các router Internet, SNMP có thể dùng để quản lý các hệ thống Unix, Window, máy in, nguồn điện… Nói chung, tất cả các thiết bị có thể chạy các phần mềm cho phép lấy được thông tin SNMP đều có thể quản lý được. Không chỉ các thiết bị vật lý mới quản lý được mà cả những phần mềm như web server, database.
Một hướng khác của quản trị mạng là theo dõi hoạt động mạng, có nghĩa là theo dõi toàn bộ một mạng trái với theo dõi các router, host, hay các thiết bị riêng lẻ. RMON (Remote Network Monitoring) có thể giúp ta hiểu làm sao một mạng có thể tự hoạt động, làm sao các thiết bị riêng lẻ trong một mạng có thể hoạt động đồng bộ trong mạng đó
IETF (Internet Engineering Task Force) là tổ chức đã đưa ra chuẩn SNMP thông qua các RFC. 
- SNMP version 1 chuẩn của giao thức SNMP được định nghĩa trong RFC 1157 và là một chuẩn đầy đủ của IETF. Vấn đề bảo mật của SNMP v1 dựa trên nguyên tắc cộng đồng, không có nhiều password, chuổi văn bản thuần và cho phép bất kỳ một ứng dụng nào đó dựa trên SNMP có thể hiểu các hiểu các chuổi này để có thể truy cập vào các thiết bị quản lý. Có 3 tiêu chuẩn trong: read-only, read-write và trap
- SNMP version 2: phiên bản này dựa trên các chuổi “community”. Do đó phiên bản này được gọi là SNMPv2c, được định nghĩa trong RFC 1905, 1906, 1907, và đây chỉ là bản thử nghiệm của IETF. Mạc dù chỉ là thử nghiệm nhưng nhiều nhà sản xuất đã đưa nó vào thực nghiệm.
- SNMP version 3: là phiên bản tiếp theo được IETF đưa ra bản đầy đủ. Nó được khuyến nghị làm bản chuẩn, được định nghĩa trong RFC 1905, RFC 1906, RFC 1907, RFC 2571, RFC 2572, RFC 2573, RFC 2574 và RFC 2575. Nó hổ trợ các loại truyền thông riêng tư và có xác nhận giữa các thực thể.
Trong SNMP có 3 vấn đề cần quan tâm: Manager, Agent và MIB (Management Information Base). MIB là cơ sở dữ liệu dùng phục vụ cho Manager và Agent. 
Manager là một server có chạy các chương trình có thể thực hiện một số chức năng quản lý mạng. Manager có thể xem như là NMS (Network Manager Stations). NMS có khả năng thăm dò và thu thập các cảnh báo từ các Agent trong mạng. Thăm dò trong việc quản lý mạng là “nghệ thuật” đặt ra các câu truy vấn đến các agent để có được một phần nào đó của thông tin. Các cảnh báo của agent là cách mà agent báo với NMS khi có sự cố xảy ra. Cảnh bảo của agent được gửi một cách không đồng bộ, không nằm trong việc trả lời truy vấn của NMS. NMS dựa trên các thông tin trả lời của agent để có các phương án giúp mạng hoạt động hiệu quả hơn. Ví dụ khi đường dây T1 kết nối tới Internet bị giảm băng thông nghiêm trọng, router sẽ gửi một thông tin cảnh báo tới NMS. NMS sẽ có một số hành động, ít nhất là lưu lại giúp ta có thể biết việc gì đã xảy ra. Các hành động này của NMS phải được cài đặt trước. 
Agent là một phần trong các chương trình chạy trên các thiết bị mạng cần quản lý. Nó có thể là một chương trình độc lập như các deamon trong Unix, hoặc được tich hợp vào hệ điều hành như IOS của Cisco trên router. Ngày nay, đa số các thiết bị hoạt động tới lớp IP được cài đặt SMNP agent. Các nhà sản xuất ngày càng muốn phát triển các agent trong các sản phẩm của họ công việc của người quản lý hệ thống hay quản trị mang đơn giản hơn. Các agent cung cấp thông tin cho NMS bằng cách lưu trữ các hoạt độn khác nhau của thiết bị. Một số thiết bị thường gửi một thông báo “tất cả đều bình thường” khi nó chuyển từ một trạng thái xấu sang một trạng thái tốt. Điều này giúp xác định khi nào một tình trạng có vấn đề được giải quyết.

Mối quan hệ giữa NMS và agent:


(hình 1)

Không có sự hạn chế nào khi NMS gửi một câu truy vấn đồng thời agent gửi một cảnh báo.
MIB có thể xem như là một cơ sở dữ liệu của các đối tượng quản lý mà agent lưu trữ được. Bất kỳ thông tin nào mà NMS có thẻ truy cập được đều được định nghĩa trong MIB. Một agent có thể có nhiều MIB nhưng tất cả các agent đều có một lọa MIB gọi là MIB-II được định nghĩa trong RFC 1213. MIB-I là bản gốc của MIB nhưng ít dùng khi MIB-II được đưa ra. Bất kỳ thiết bị nào hổ trợ SNMP đều phải hổ trợ MIB-II. MIB-II định nghĩa các tham số như tình trạng của interface (tốc độ của interface, MTU, các octet gửi, các octet nhận. ...) hoặc các tham số gắn liền với hệ thống (định vị hệ thống, thông tin liên lạc với hệ thống, ...). Mục đích chính của MIB-II là cung cấp các thông tin quản lý theo TCP/IP. Có nhiều 

kiểu MIB giúp quản lý cho các mục đích khác nhau:
• ATM MIB (RFC 2515) 
• Frame Relay DTE Interface Type MIB (RFC 2115) 
• BGP Version 4 MIB (RFC 1657) 
• RDBMS MIB (RFC 1697)
• RADIUS Authentication Server MIB (RFC 2619)
• Mail Monitoring MIB (RFC 2249)
• DNS Server MIB (RFC 1611) 

Nhưng nhà sản xuất cũng như người dùng có thể định nghĩa các biến MIB riêng cho họ trong từng tình huống quản lý của họ.
Quản lý Host Resource cũng là một phần quan trọng của quản lý mạng. Trước đây, sự khác nhau giữa quản lý hệ thống kiểu cũ và quản lý mạng không được xác định, nhưng bây giờ đã được phân biệt rõ ràng. RFC 2790 đưa ra Host Resource với định nghĩa tập hợp cá đối tượng cần quản lý trong hệ thống Unix và Window. Một số đối tượng đó là: dung lượng đĩa, số user của hệ thống, số tiến trình đang chạy của hệ thống và các phần mềm đã cài vào hệ thống. Trong một thế giới thương mại điện tử, các dịch vụ như web ngày càng trở nên phổ biến nên việc đảm bảo cho các server hoạt động tốt là việc hết sức quan trọng
RMON (Remote Monitoring) hay còn gọi là RMON v1 được định nghĩa trong RFC 2819. RMON v1 cung cấp cho NMS các thông tin dạng packet về các thực thể trong LAN hay WAN. RMON v2 được xây dựng trên RMON v1 bởi những nhà cung cấp mạng và cung cấp thông tin ở lớp application. Thông tin có thể thu được bằng nhiều cách.. Một cách trong đó là đặt một bộ phận thăm dò của RMON trên mỗi phân đoạn mạng muốn theo dõi. RMON MIB được thiết kế để các RMON có thể chạy khi không kết nối logic giữa NMS và agent, có thể lấy được thông tin mà không cần chờ truy vấn của NMS. Sau đó, khi NMS muốn truy vấn, RMON sẽ trả lời bằng các thông tin thu thập được. Một đặc tính khác là ta có thể đặt ngưỡng cho một loại lỗi nào đó, và khi lỗi vượt quá ngưỡng đặt ra, RMON gửi một cảnh báo cho NMS.
2. SMI:
SMI (The Structure of Management Information) cung cấp cho chúng ta cách định nghĩa, lưu trữ các đối tượng quản lý và các thuộc tính của chúng (cấu tru). SMI đơn giản gồm có 3 đặc tính sau:
- Name hay OID (object identifier): định nghĩa tên của đối tượng. Tên thường ở 2 dạng: số hay các chữ có ý nghĩa nào đó về đối tượng. Trong dạng này hay dạng kia, tên thường khó nhớ hay bất tiện
- Kiểu và cú pháp: Kiểu dữ liệu của object cần quản lý được định nghĩa trong ASN.1( Abstract Syntax Notation One). ASN.1 chỉ ra cách dữ liệu được biểu diển và truyền đi giữa Manager và agent. Các thông tin mà ASN.1 thông báo là độc lập với hệ điều hành. Điều này giúp một may chạy WindowNT có thể liên lạc với một máy chạy Sun SPARC dễ dàng.
- Mã hóa: mã hóa các đối tượng quản lý thành các chuổi octet dùng BER (Basic Encoding Rules). BER xây dựng cách mã hóa và giải mã để truyền các đối tượng qua các môi trường truyền như Ethernet.
Tên hay OID được tổ chức theo dạng cây. Tên của một đối tượng được thành lập từ một dãy các số nguyên hay chữ dựa theo các nút trên cây, phân cách nhau bởi dấu chấm


(hình 2) 

theo mô hình cây trên ta có OID của nhánh internet:
internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 }
directory OBJECT IDENTIFIER ::= { internet 1 }
mgmt OBJECT IDENTIFIER ::= { internet 2 }
experimental OBJECT IDENTIFIER ::= { internet 3 }
private OBJECT IDENTIFIER ::= { internet 4 }
Trong mô hình trên, MIB-II thuộc nhánh mgmt:


(hình 3)

MIB-II có 10 nhánh con được định nghĩa trong RFC 1213, kế thừa từ MIB-I trong RFC 1066. Mỗi nhánh có một chức năng riêng:

- system (1.3.6.1.2.1.1) Định nghĩa một danh sách các đối tượng gắn liền với hoạt động của hệ thống như: thời gian hệ thống khởi động tới bây giờ, thông tin liên lạc của hệ thống và tên của hệ thống.
- interfaces (1.3.6.1.2.1.2) Lưu giữ trạng thái của các interface trên một thực thể quản lý. Theo dõi một interface “up” hoặc “down”, lưu lại các octet gửi và nhận, octet lỗi hay bị hủy bỏ.
- at (1.3.6.1.2.1.3) Nhóm at (address translation) bị phản đối, nó chỉ cung cấp khả năng tương thích ngược. Nhóm này được bỏ từ MIB-III trở đi.
- ip (1.3.6.1.2.1.4) Lưu giữ nhiều thông tin liên quan tới giao thức IP, trong đó có phần định tuyến IP.
- icmp (1.3.6.1.2.1.5) Lưu các thông tin như gói ICMP lỗi, hủy.
- tcp (1.3.6.1.2.1.6) Lưu các thông tin khác dành riêng cho trạng thái các kết nối TCP như: đóng, lắng nghe, báo gửi…
- udp (1.3.6.1.2.1.7) Tập hợp các thông tin thống kê cho UDP, các datagram vào và ra, …
- egp (1.3.6.1.2.1.8) Lưu các tham số về EGP và bảng EGP lân cận.
- Transmission (1.3.6.1.2.1.10) Không có đối tượng nào trong nhóm này, nhưng nó định nghĩa các môi trường đặc biệt của MIB.
- snmp (1.3.6.1.2.1.11) Đo lường sự thực thi của SNMP trên các thực thể quản lý và lưu các thông tin như số các gói SNMP nhận và gửi.

3. Hoạt động của SNMP:
Hoạt động của SNMP theo mô hình sau:



- get
- get-next
- get-bulk (cho SNMP v2 và SNMP v3)
- set
- get-response
- trap (cảnh báo)
- notification (cho SNMP v2 và SNMP v3)
- inform (cho SNMP v2 và SNMP v3)
- report (cho SNMP v2 và SNMP v3)

3.1. ”get”: ”get” được gửi từ NMS yêu cầu tới agent. Agent nhận yêu cầu và xử lý với khả năng tốt nhất có thể. Nếu một thiết bị nào đó đang bận tải nặng, như router, nó không có khả năng trả lời yêu cầu nên nó sẽ hủy lời yêu cầu này. Nếu agent tập hợp đủ thông tin cần thiết cho lời yêu cầu, nó gửi lại cho NMS một ”get-response”:



Để agent hiểu được NMS cần tìm thông tin gì, nó dựa vào một mục trong ”get” là ”variable binding” hay varbind. Varbind là một danh sách các đối tượng của MIB mà NMS muốn lấy từ agent. Agent hiểu câu hỏi theo dạng: OID=value để tìm thông tin trả lời. Câu hỏi truy vấn cho trường hợp trong hình vẽ trên:

$ snmpget cisco.ora.com public .1.3.6.1.2.1.1.6.0
system.sysLocation.0 = ""

Đây là một câu lệnh ”snmpget” trên Unix. ”cisco.ora.com” là tên của thiết bị, ”public” là chuổi chỉ đây là yêu cầu chỉ đọc (read-only), ”.1.3.6.1.2.1.1.6.0” là OID. ”.1.3.6.1.2.1.1” chỉ tới nhóm ”system” trong MIB. ”.6” chỉ tới một trường trong ”system” là ”sysLocation”. Trong câu lệnh này ta muốn hỏi Cisco router rằng việc định vị hệ thống đã được cài đặt chưa. Câu trả lời system.sysLocation.0 = "" tức là chưa cài đặt. Câu trả lời của ”snmpget” theo dạng của varbind: OID=value. Còn phần cuối trong OID ở ”snmpget”; ”.0” nằm trong quy ước của MIB. Khi hỏi một đối tượng trong MIB ta cần chỉ rõ 2 trường ”x.y’, ở đây là ”.6.0”. ”x” là OID thực tế của đối tượng. Còn ”.y” được dùng trong các đối tượng có hướng như một bảng để hiểu hàng nào của bảng, với trường hợp đối tượng vô hướng như trường hợp này ”y” = ”0”. Các hàng trong bảng được đánh số từ số 1 trở đi.
Câu lệnh ”get” hữu ích trong việc truy vấn một đối tượng riêng lẻ trong MIB. Khi muốn biết thông tin về nhiều đối tượng thì ”get” tốn khá nhiều thời gian. Câu lệnh ’get-next” giải quyết được vấn đề này.

3.2 ”get-next”: ”get-next” đưa ra một dãy các lệnh để lấy thông tin từ một nhóm trong MIB. Agent sẽ lần lượt trả lời tất cả các đối tượng có trong câu truy vấn của ”get-next” tương tự như ”get”, cho đến khi nào hết các đối tượng trong dãy. Ví dụ ta dùng lệnh ”snmpwalk”. ”snmpwalk’ tương tự như ”snmpget’ nhưng không chỉ tới một đối tượng mà chỉ tới một nhánh nào đó:

$snmpwalk cisco.ora.com public system
system.sysDescr.0 = "Cisco Internetwork Operating System Software 
..IOS (tm) 2500 Software (C2500-I-L), Version 11.2(5), RELEASE 
SOFTWARE (fc1)..Copyright (c) 1986-1997 by cisco Systems, Inc...
Compiled Mon 31-Mar-97 19:53 by ckralik"
system.sysObjectID.0 = OID: enterprises.9.1.19
system.sysUpTime.0 = Timeticks: (27210723) 3 days, 3:35:07.23
system.sysContact.0 = ""
system.sysName.0 = "cisco.ora.com"
system.sysLocation.0 = ""
system.sysServices.0 = 6

Ở đây ta muôn lấy thông tin của nhóm ”system”, agent sẽ gửi trả toàn bộ thông tin của ”system” theo yêu cầu. Quá trình tìm nhóm ”system” trong MIB thực hiện theo cây từ gốc, đến một nút nếu có nhiều nhánh thì chọn nhánh tìm theo chỉ số của nhánh từ nhỏ đến lớn:



3.3 ”get-bulk”: ”get-bulk” đượ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 ”get-bulk”, agent sẽ gửi cang 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 ”get-bulk” 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 ”get-next” cho các đối tượng còn lại:



$ snmpbulkget -v2c -B 1 3 linux.ora.com public sysDescr ifInOctets ifOutOctets
system.sysDescr.0 = "Linux linux 2.2.5-15 #3 Thu May 27 19:33:18 EDT 1999 i686"
interfaces.ifTable.ifEntry.ifInOctets.1 = 70840
interfaces.ifTable.ifEntry.ifOutOctets.1 = 70840
interfaces.ifTable.ifEntry.ifInOctets.2 = 143548020
interfaces.ifTable.ifEntry.ifOutOctets.2 = 111725152
interfaces.ifTable.ifEntry.ifInOctets.3 = 0
interfaces.ifTable.ifEntry.ifOutOctets.3 = 0

ở đây, ta hỏi về 3 varbind: sysDescr, ifInOctets, và ifOutOctets. Tổng số varbind được tính theo công thức 
N + (M * R)
N: nonrepeater, tức số các đối tượng vô hướng
M: max-repeatition
R: số các đối tượng có hướng trong yêu cầu
chỉ có sysDescr là vô hướng è N = 1
M có thể đặt cho là 3 , tức là 3 trường cho mỗi ifInOctets và ifOutOctets. Có 2 đối tượng có hướng là ifInOctets và ifOutOctets è R = 2
Tổng số có 1 + 3*2 = 7 varbind
Còn trường ”–v2c” là do ”get-bulk” là câu lệnh của SNMPv2 nên sử dụng ”-v2c” để chỉ rằng sử dụng PDU của SNMPv2. ”-B 1 3” là để đặt tham số N và M cho lệnh.

3.4 ”set”: để thay đổi giá trị của một đối tượng hoặc thêm một hàng mới vào bảng. Đối tượng này cần phải được định nghĩa trong MIB là ”read-write” hay ”write-only”. NMS có thể dùng ”set’ để đặt giá trị cho nhiều đối tượng cùng một lúc:




$ snmpget cisco.ora.com public system.sysLocation.0
system.sysLocation.0 = ""
$ snmpset cisco.ora.com private system.sysLocation.0 s "Atlanta, GA"
system.sysLocation.0 = "Atlanta, GA"
$ snmpget cisco.ora.com public system.sysLocation.0
system.sysLocation.0 = "Atlanta, GA"

Câu lệnh đầu là dung ”get” để lấy giá trị hiện tại của ”system.sysLocation”. Trong câu lệnh ”snmpset” các trường ”cisco.ora.com” và ”system.sysLocation.0” có ý nghĩa giống với ”get”. ”private” để chỉ đối tượng ”read-write’, và đặt giá trị mới bằng: ”s "Atlanta, GA"”. ”s” tức là đặt giá trị của ”system.sysLocation.0” thành string, và giá trị mới là "Atlanta, GA" . Varbind này được định nghĩa trong RFC 1213 là kiểu string tối đa 255 ký tự:


sysLocation OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The physical location of this node (e.g., 'telephone closet,
3rd floor')."
::= { system 6 }

Có thể cài đặt nhiều đối tượng cùng lúc, tuy nhiên nếu có một hành động bị lỗi, toàn bộ sẽ bị hủy bỏ.

3.5 Error Response của ”get”, ”get-next”, ”get-bulk” và ”set”: Có nhiều loại lỗi báo lại từ agent:

SNMPv1 Error Message Ý nghĩa
noError(0) Không có lỗi
tooBig(1) Yêu cầu quá lớn để có thể dồn vào một câu 
trả lời
noSuchName(2) OID yêu cầu không tìm thấy, tức không tồn 
tại ở agent
badValue(3) Câu lệnh “set” dùng không đúng với các 
object “read-write” hay “write-only”
readOnly(4) Lỗi này ít dùng. Lỗi “noSuchName” tương 
đương với lỗi này
genErr(5) Dùng cho tất cả các lỗi còn lại, không nằm 
trong các lỗi trên

Các loại lỗi của SNMPv1 mang tính chất chung nhất, không rõ ràng. Do đó SNMPv2 đưa ra thêm một số loại lỗi như sau:

SNMPv2 Error Message Ý nghĩa
noAccess(6) Lỗi khi lệnh “set” cố gắng xâm nhập vào 
một biến cấm xâm nhập. Khi đó, biến đó 
có trường “ACCESS” là “not-accessible”
wrongType(7) Lỗi xảy ra khi lệnh “set” đặt một kiểu dữ 
liệu khác với kiểu định nghĩa sẵn của đối 
tượng. Ví dụ khi “set” đặt giá trị kiểu 
string cho một đối tượng kiểu số nguyên 
INTEGER
wrongLength(8) Lỗi khi lệnh “set” đưa vào một giá trị có 
chiều dài lớn hơn chiều dài tối đa của 
đối tượng
wrongEncoding(9) Lỗi khi lệnh “set” sử dụng cách mã hóa 
khác với cách đối tượng đã định nghĩa.
wrongValue(10) Một biến được đặt một giá trị mà nó không 
hiểu. Khi một biến theo kiểu liệt kê 
“enumeration” được đặt một giá trị không 
theo kiểu liệt kê.
noCreation(11) Lỗi khi cố đặt một giá trị cho một biến 
không tồn tại hoặc tạo một biến không có 
trong MIB 
inconsistentValue Một biến MIB ở trạng thái không nhất 
quán, và nó không chấp nhận bất cứ câu 
lệnh “set” nào.
resourceUnavailable(13) Không có tài nguyên hệ thống để thực hiện 
lệnh “set”
commitFailed(14) Đại diện cho tất cả các lỗi khi lệnh 
“set” thất bại
undoFailed(15) Một lệnh “set” không thành công và agent 
không thể phục hồi lại trạng thái trước 
khi lệnh “set” bắt đầu thất bại.
authorizationError(16) Một lệnh SNMP không được xác thực, khi 
một người nào đó đưa ra mật mã không 
đúng. 
notWritable(17) Một biến không chấp nhận lệnh “set”
inconsistentName(18) Cố gắng đặt một giá trị, nhưng việc cố 
gắng thất bại vì biến đó đang ở tình 
trạng không nhất quán.

3.6 SNMP Traps: Trap là cảnh báo của agent tự động gửi cho NMS để NMS biết có tình trạng xấu ở agent



Khi nhận được một ”trap” từ agent, NMS không trả lời lại bằng ”ACK”. Do đó agent không thể nào biết được là lời cảnh báo của nó có tới được NMS hay không. Khi nhận được một ”trap” từ agent, nó tìm xem ”trap number” để hiểu ý nghĩa của ”trap” đó:

Số và tên kiểu trap Định nghĩa
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, 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”.
linkUp (3) Gửi đi khi một interface trở lại trạng thái “up”.
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.
”trap” được đưa ra trong MIB qua ”rdbmsOutOfSpace”:

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

3.7 SNMP Notification:
Để chuẩn hóa định dạng PDU ”trap” của SNMPv1 do PDU của ”get” và ”set” khác nhau, SNMPv2 đưa ra ”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 transitioned into some other state (but not into the notPresent state). This other state is indicated by the included value of ifOperStatus."
::= { snmpTraps 3 }


OID của “trap” này là 1.3.6.1.6.3.1.1.5.3, tức iso.org.dod.internet.snmpV2.snmpModules.snmpMIB.sn mpMIBObjects.snmpTraps.linkDown.
3.8 SNMP inform: SNMPv2 cung cấp cơ chế truyền thông giữa những NMS với nhau, gọi là SNMP inform. Khi một NMS gửi một SNMP inform cho một NMS khác, NMS nhận được sẽ gửi trả một ACK xác nhận sự kiện. Việc này giống với cơ chế của “get” và “set”.
3.9 SNMP report: được định nghĩa trong bản nháp của SNMPv2 nhưng không được phát triển. Sau đó được đưa vào SNMPv3 và hy vọng dùng để truyền thông giữa các hệ thống SNMP với nhau