ถ้าจะพูดถึงเวอร์ชันของ SNMP ที่มีอยู่ 3 เวอร์ชัน นักพัฒนาระบบทั่วไปส่วนใหญ่ชื่นชอบมากที่สุดก็ต้องบอกว่าเป็นเวอร์ชันที่ 1 หรืออาจเรียกอีกชื่อว่า SNMPv1
การสื่อสารข้อมูลในงานอุตสาหกรรม
ตอนที่ 12 มารู้จักโปรโตคอล SNMP (ตอนที่ 2)
พิชิต จินตโกศลวิทย์
pichitor@yahoo.com
SNMPv1
ถ้าจะพูดถึงเวอร์ชันของ SNMP ที่มีอยู่ 3 เวอร์ชัน นักพัฒนาระบบทั่วไปส่วนใหญ่ชื่นชอบมากที่สุดก็ต้องบอกว่าเป็นเวอร์ชันที่ 1 หรืออาจเรียกอีกชื่อว่า SNMPv1 ทำไมเวอร์ชันที่ 1 ถึงเป็นที่ชื่นชอบก็เพราะว่าสามารถทำการศึกษา และพัฒนาระบบงานให้สนับสนุน SNMPv1 ได้ไม่ยาก เหมาะสมกับคำว่า Simple หรือง่าย ๆ โดยเวอร์ชันที่ 1 มีฟังก์ชันในการทำงานจำนวนไม่กี่ฟังก์ชัน และลักษณะการทำงานไม่ซับซ้อน ดังต่อไปนี้
• Get-Request เป็นคำสั่งร้องขอข้อมูลที่ตำแหน่งแรกของโครงสร้างข้อมูล
• Get-Next-Request เป็นคำสั่งร้องขอข้อมูลตำแหน่งถัดไปตามโครงสร้างข้อมูล
• Set-Request เป็นคำสั่งขอเขียนข้อมูลลงไปในตัวอุปกรณ์
• Get-Response เป็นการตอบสนองการร้องขอข้อมูล
• Trap เป็นการตั้งเงื่อนไขการส่งข้อมูลจากอุปกรณ์หรือเอเยนต์โดยไม่ต้องมีการร้องขอซึ่งโดยทั่วไปมี 2 วิธี นั้นคือ
1. Generic Trap
2. Specific Trap
โดยฟังก์ชันดังที่ได้กล่าวข้างต้นจะทำงานบนโครงสร้างข้อมูลแบบรูปร่างต้นไม้ (Tree-like Data Structure) ที่ประกอบด้วยออปเจ็กต์ที่บรรจุด้วยข้อมูลของอุปกรณ์อยู่ตามกิ่งก้านสาขา (Branch) ของต้นไม้ ซึ่งโครงสร้างและรูปแบบจะถูกกำหนดตามมาตรฐาน RFC1155 หรือ เรียกอีกอย่างว่า SMIv1 โดยจะระบุถึงวิธีการจัดการออปเจ็กต์ เช่น การตั้งชื่อออปเจ็กต์ การกำหนดชนิดข้อมูลของแต่ละออปเจ็กต์ โดยวิธีการนิยามออปเจ็กต์ใน SNMPv1 สามารถแบ่งย่อยได้ 3 คุณสมบัติ ดังต่อไปนี้
1. ชื่อ (Name)
ชื่อของออปเจ็กต์ หรือ เรียกอีกอย่างทางเทคนิคว่า OID (Object Identifier) จะต้องไม่ซ้ำกับชื่อของออปเจ็กต์ตัวอื่น ๆ รูปแบบชื่อของออปเจ็กต์จะปรากฏได้สองรูปแบบ คือ เป็นลักษณะของตัวเลข หรือ เป็นลักษณะตัวอักษรที่สามารถอ่านได้โดยง่ายและจำง่ายกว่า จุดประสงค์การมีรูปแบบสองรูปแบบก็คล้ายคลึงกับจุดประสงค์ของหมายเลข IP (Internet Protocol) และชื่อ URL (Uniform Resource Locator) ซึ่งอันที่จริงทั้งสองรูปแบบของ SNMP ก็มีความยาวที่ค่อนข้างยาว และจดจำได้ยากไม่ทิ้งกันเนื่องจากโครงสร้างของข้อมูลมีความใหญ่นั้นเอง ทำให้ยังต้องเปิดคู่มือช่วย หรือใช้เครื่องมือหรือซอฟต์แวร์ช่วยในการทำงาน
2. ชนิด และ ซินเท็กซ์ (Type และ Syntax)
ชนิดข้อมูลของออปเจ็กต์จะถูกนิยามโดยใช้ซินเท็กซ์ตามมาตรฐาน ASN.1 (Abstract Syntax Notation One) การนิยามแบบ ASN.1 คือการระบุวิธีการเปลี่ยนรูปแบบการแสดงข้อมูลให้เป็นมาตรฐานกลางก่อนที่จะส่งไปยังตัวเมเนเจอร์ หรือเอเยนต์ที่อาจใช้ระบบปฏิบัติการที่แตกต่างกัน ข้อดีของ ASN.1 คือเป็นรูปแบบของข้อมูลที่ไม่ยึดติดกับชนิดฮาร์ดแวร์ นั้นหมายความว่าไม่ต้องกังวลในเรื่องการส่งผ่านข้อมูลระหว่างเครื่องคอมพิวเตอร์ต่างแพลตฟอร์มซึ่งอาจมีความแตกต่างในการเรียงไบต์สูงกับไบต์ต่ำ โดยจะมีการกล่าวรายละเอียดเพิ่มเติม และยกตัวอย่างการส่งข้อมูลจริง ๆ ในภายหลัง
3. การเข้ารหัส (Encoding)
ทุกส่วนของออปเจ็กต์จะถูกเข้ารหัสในรูปแถวของไบต์หรือออกเตตโดยใช้หลักการ BER (Basic Encoding Rules) เพื่อให้ข้อมูลสามารถส่งผ่านสื่อสัญญาณได้ง่าย เช่น เครือข่ายอีเทอร์เน็ต โดยจะกล่าวรายละเอียดเพิ่มเติมและยกตัวอย่างการส่งข้อมูลจริง ๆ ในภายหลังเช่นกัน
* การตั้งชื่อ OID
แต่ละออปเจ็กต์สามารถจัดให้อยู่ในโครงสร้างต้นไม้ โดยชื่อของออปเจ็กต์ หรือ OID นั้น จะประกอบด้วยชุดของหมายเลขจำนวนเต็มตามจำนวนโหนดที่มันอยู่ภายใต้โครงสร้างโดยใช้เครื่องหมายจุด หรือ ดอต (“.”) เป็นตัวคั่นกลางระหว่างชั้น หรือระดับ ถึงแม้ว่าจะมีการใช้ชื่อเป็นตัวแทนของแต่ละโหนด หรือ ระดับชั้น แต่จริง ๆ แล้วก็ไม่ให้ความรู้สึกที่แตกต่างกัน โดยชื่อที่เป็นตัวอักษร หรือเลขจำนวนเต็มก็สามารถใช้อ้างอิงถึงตำแหน่งของแต่ละโหนด ดังนั้นจึงสามารถใช้การจัดเรียงลำดับชื่อ หรือหมายเลขเพื่อการอ้างถึง OID หรือออปเจ็กต์นั้น ๆ รูปที่ 4 แสดงโครงสร้างต้นไม้ระดับพื้นฐานของ SNMPv1
รูปที่ 4 โครงสร้างต้นไม้ของ SMI
ตามโครงสร้างต้นไม้ที่แสดงดังรูปที่ 4 โหนดที่อยู่บนสุดจะถูกเรียกว่ารูต (Root) และโหนดที่มีโหนดอื่นอยู่ภายใต้จะถูกเรียกว่าซับทรี (Subtree) แต่สำหรับโหนดสุดท้าย หรือโหนดที่ไม่มีโหนดอื่นอยู่ภายใต้จะเรียกว่า ลีฟโหนด (Leaf Node) จากรูปตัวอย่างที่ 4 รูตคือจุดเริ่มต้นของโครงสร้างต้นไม้สามารถเรียกว่า รูตโหนด (Root-Node) จากรูปที่ 4 โหนด iso(1) จะเป็นเป็นเพียงโหนดเดียวที่เป็นซับทรี สำหรับโหนด ccitt(0) และ joint(2) จะเป็นเพียงลีฟโหนดเท่านั้น เนื่องจากที่จริงแล้วไม่ได้อยู่ภายการควบคุมของมาตรฐาน SNMP แต่สร้างไว้เพื่อระบบอื่น ๆ นอกมาตรฐาน
แต่ละออปเจ็กต์หรือโหนดจะมีหมายเลข OID กำกับ และถูกเชื่อมโยงซึ่งกันและกันโดยอ้างอิงชื่อและลำดับ การอ้างอิงแบบตัวเลขจะใช้การเรียงลำดับและเครื่องหมายจุดคั้นเพื่อบ่งบอกตำแหน่งของออปเจ็กต์ในตัวเอเยนต์ โดยรูปแบบการอ้างอิงจะคล้ายคลึงกับการอ้างอิงหมายเลข IP เพื่อลดการจดจำ จากรูปที่ 4 เราสามารถอ้างถึงซับทรี internet ได้ดังนี้ คือ 1.3.6.1 หรืออ้างอิงโดยชื่อ คือ iso.org.dod.internet
อีกประการหนึ่งซับทรียังสามารถถูกเรียกได้อีกอย่างว่าบรานช์ (Branch) จากรูปที่ 4 ได้ว่าบรานช์ mgmt จะใช้นิยามชุดข้อมูลมาตรฐานสำหรับการบริหารจัดการอินเทอร์เน็ตหรือการติดต่อระบบเครือข่ายของอุปกรณ์ ในส่วนของบรานช์ experimental นั้นถูกออกแบบไว้สำหรับทำการทดลองหรือออกแบบออปเจ็กต์หรือข้อมูลชนิดใหม่ สำหรับบรานช์ private ใช้สำหรับสร้างออปเจ็กต์พิเศษที่ถูกนิยามโดยผู้ผลิตอุปกรณ์นั้น ๆ หรือ เพื่อตอบสนองความต้องการแบบพิเศษของผู้ใช้แต่ละรายโดยเฉพาะ ตัวอย่างการนิยามสร้างโครงสร้าง SMI ของซับทรี 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 3}
จะเห็นว่าบรรทัดแรกเป็นการประกาศการสร้างออปเจ็กต์ internet นั้นคือ OID หมายเลข 1.3.6.1 ซึ่งจริง ๆ แล้วเป็นซับทรีภายใต้ iso.org.dod หรือ 1.3.6 ส่วนการประกาศอีก 4 บรรทัดก็คือการสร้างซับทรีย่อยลงไปอีกหนึ่งระดับ หรือ เรียกอีกอย่างว่าเป็นบรานช์ของโหนด internet นั้นเอง เช่น บรานช์ directory จะใช้ซินเท็กซ์ หรือการนิยามดังนี้ {Internet 1} ซึ่งบ่งบอกว่ามันเป็นส่วนหนึ่งของซับทรี internet โดยมีหมายเลขบอกลำดับกำกับเพื่อการจำแนก ทำให้ซับทรีดังกล่าวมีหมายเลข OID เท่ากับ 1.3.6.1.1 สำหรับการสร้าง OID ของตัวอื่น ๆ เช่น บรานช์ mgmt ก็ใช้หลักการเดียวกัน ดังนั้นก็จะได้ หมายเลข OID เท่ากับ 1.3.6.1.2 เรียงลำดับกันไป
ในปัจจุบันยังมีออปเจ็กต์ชนิดพิเศษที่อยู่ภายใต้ซับทรี private ซึ่งเป็นการออกแบบโครงสร้างเพื่อเปิดช่องให้ผู้ผลิตฮาร์ดแวร์ และซอฟต์แวร์ ได้นิยามออปเจ็กต์ขึ้นมาใช้เองเพื่อจุดประสงค์พิเศษต่าง ๆ ที่อาจจะเกิดขึ้นได้โดยมีการนิยามตาม SMI ดังต่อไปนี้
enterprises OBJECT IDENTIFIER ::= {private 1}
ความจริงอีกประการหนึ่งนั้นคือหมายเลขออปเจ็กต์ของโหนดในซับทรี private.enterprise ไม่สามารถตั้งเองได้อย่างอิสระ แต่ยังถูกกำหนดโดยหน่วยงานสากล IANA (Internet Assigned Numbers Authority) เพื่อป้องกันการตั้งซ้ำซ้อน ยกตัวอย่างเช่น บริษัท CISCO จะได้หมายเลขภายใต้โหนด enterprise เป็นหมายเลข 9 ดังนั้นหมายเลข OID ของ CISCO จะเท่ากับ iso.org.dod.internet.private.enterpises.cisco หรือ 1.3.6.1.4.1.9 และแล้วโหนดภายใต้บรานช์นี้ของบริษัท CISCO จะเป็นอิสระในการนิยามออปเจ็กต์ตามความต้องการซึ่งเป็นประโยชน์อย่างมาก และเป็นการไม่จำกัดขอบเขตในการพัฒนาสิ่งใหม่ใหม่ อีกอย่างหนึ่งการลงทะเบียนของหมายเลขบรานช์ประเภท Private นั้นไม่เสียค่าใช้จ่ายใด ๆ โดยสามารถลงทะเบียนขอหมายเลขผ่านเว็บไซต์ดังนี้ http://www.isi.edu/cgi-bin/iana/enterprise.pl
* การนิยาม OID
การนิยาม OID นั้นจะทำด้วยซินเท็กซ์ (Syntax) หรือ คำสั่งในการนิยาม) โดยจะถูกกำกับดูแลด้วยมาตรฐาน ASN.1 สำหรับ SMIv1 จะมีการกำหนดชนิดของข้อมูล (Data Type) เพื่อบ่งบอก หรือเป็นแนะนำว่าเป็นข้อมูลนั้นเป็นชนิดใด โดยทั่วไปใช้ทำอะไร ดังตารางดังต่อไปนี้
ตาราง ชนิดข้อมูลที่สนับสนุนโดย SMIv1
อีกจุดประสงค์หนึ่งของชนิดข้อมูลของออปเจ็กต์ ก็คือเพื่อการจัดกลุ่มของออปเจ็กต์ให้ง่ายต่อการจัดการ หรือที่เรียกอีกอย่างว่า MIB (Management Information Base) โดยอาจจะมองว่า MIB เป็นโครงสร้างฐานข้อมูลใช้ในการบ่งบอกคุณสมบัติของอุปกรณ์นั้น ๆ ก็ได้ ในการทำงานกับซอฟต์แวร์ประเภทบริหารจัดการอุปกรณ์เครือข่ายโดยทั่วไปใช้มักจะใช้ไฟล์ MIB ในการรับทราบคุณสมบัติของอุปกรณ์ที่จะจัดการ โดยวิธีการง่าย ๆ คือ การโหลด หรือการคอมไพล์ไฟล์ MIB ของตัวอุปกรณ์นั้น ๆ เข้าไปในระบบ สิ่งที่สำคัญที่ต้องเข้าใจเกี่ยวกับไฟล์ MIB ก็คือซินเท็กซ์ (Syntax) หรือคำสั่งนั้นเอง โดยปัจจุบันจะใช้มาตรฐานที่เรียกว่า MIB-II ซึ่งเป็นที่นิยมมาก ตัวอย่างเนื้อหาหรือคำสั่งในการนิยามของไฟล์ MIB ดังต่อไปนี้
RFC1213-MIB DEFINITION: = BEGIN
IMPORTS
mgmt, NetworkAddress, IpAddress, Counter, Gauge,
TimeTicks
FROM RFC1155-SMI
OBJECT-TYPE
FROM RFC 1212;
mib-2 OBJECT IDENTIFIER ::= {mgmt 1}
-- groups in MIB-II
system OBJECT IDENTIFIER ::= {mib-2 1}
interfaces OBJECT IDENTIFIER ::= {mib-2 2}
at OBJECT IDENTIFIER ::= {mib-2 3}
ip OBJECT IDENTIFIER ::= {mib-2 4}
icmp OBJECT IDENTIFIER ::= {mib-2 5}
tcp OBJECT IDENTIFIER ::= {mib-2 6}
udp OBJECT IDENTIFIER ::= {mib-2 7}
egp OBJECT IDENTIFIER ::= {mib-2 8}
transmission OBJECT IDENTIFIER ::= {mib-2 10}
snmp OBJECT IDENTIFIER ::= {mib-2 11}
-- the Interfaces table
-- The Interface table contains information on the entity’s
-- interfaces. Each interface is thought of as being
-- attached to a ‘subnetwork’ Note that this term should
-- not be confused with ‘subnet’ which refers to an
-- addressing-partitioning scheme used in the Internet
-- suite of protocols.
ifTable OBJECT-TYPE
SYNTAX SEQUENCE OF IfEntry
ACCESS not-accessable
STATUS mandatory
DESCRIPTION
“A list of interface entries. The number of entries is
given by the value of ifNumber.”
::= {interface 2}
ifEntry OBJECT-TYPE
SYNTAX IfEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
“An interface entry containing objects at the subnetwork
Layer and below for a particular interface.”
INDEX {ifIndex}
::= {ifIndex 1}
IfEntry ::=
SEQUENCE {
ifIndex
INTEGER,
ifDescr
DisplayString,
ifType
INTEGER,
ifMtu
INTEGER,
ifSpeed
Gauge,
ifPhysAddress
PhysAddress,
ifAdminStatus
INTEGER,
ifOperStatus
INTEGER,
ifLastChange
TimeTicks,
ifInOctets
Counter,
ifInUcastPkts
Counter,
ifInNUcastPkts
Counter,
ifInDiscards,
Counter,
ifInErrors
Counter,
ifInUnknownProtos
Counter,
ifOutOctets
Counter,
ifOutUcastPkts
Counter,
ifOutNUcastPkts
Counter,
ifOutDiscards
Counter,
ifOutErrors
Counter,
ifOutQLen
Gauge,
ifSpecific
OBJECT IDENTIFIER
}
ifIndex OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
“A unique value for each interface. Its value ranges
Between 1. and the value of ifNumber. The value for each
Each interface must remain constant at least from one
Reinitialization of the entity’s network-management
System to the next reinitiallization.”
::= {ifEntry 1}
ifDescr OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
ACCESS read-only
STATUS mandatory
DESCRIPTION
“A textual string containing information about the
Interface. This string should include the name of
The manufacturer, the product name, and the version
Of the hardware interface.”
::= {ifEntry 2}
END
บรรทัดแรกคือการตั้งชื่อ MIB สำหรับตัวอย่างนี้ ชื่อที่ตั้งคือ RFC1213-MIB (RFC1213 เป็นหมายเลขมาตรฐานสำหรับ MIB-II บ่งบอกว่าไฟล์นี้ใช้มาตรฐาน MIB-II) รูปแบบการนิยามมาตรฐานจะต้องเป็นลักษณะนี้เสมอโดยมีคำสั่งสำคัญอันหนึ่งนั้นคือ IMPORTS ซึ่งเป็นการอนุญาตให้ผู้ใช้ทราบถึงข้อมูลหรือออปเจ็กต์ของตัวอุปกรณ์จากไฟล์ MIB โดย IMPORT จะทำงานคู่กับเงื่อนไข FROM ซึ่งบ่งบอกข้อมูลดังกล่าวมาจากการนิยามมาตรฐานใด โดยตัวอย่างจะเห็นว่าข้อมูลบางส่วนจะมาจากมาตรฐาน SMIv1 หรือ RFC1155 ดังที่กล่าวมาแล้วข้างต้นดังต่อไปนี้
* NetworkAddress
* IpAddress
* Counter
* Gauge
* TimeTicks
ในอีกส่วนหนึ่งก็คือข้อมูลแบบ OBJECT-TYPE ที่ถูกนิยามโดยอีกมาตรฐานของ MIB-2 นั้นคือ RFC 1212 ซึ่งเป็นการนิยามที่กำหนดวิธีการสร้างไฟล์ MIB อีกรูปแบบ โดยที่ OID ที่จะถูกใช้งานจะถูกกำหนดในไฟล์ MIB ดังกล่าวตามเซ็คชันเป็นส่วน ๆ ซึ่งจะมีการเชื่อมต่อซึ่งกันและกันตามซินเท็กซ์ อย่างเช่น กลุ่มของบรรทัดที่นิยามซับทรี mib-2 จะพบว่า mib-2 จะถูกนิยามให้อยู่ภายใต้โหนด mgmt โดยกำหนดโหนดให้หมายเลขที่ .1 ซึ่งเราก็ทราบดีว่า mgmt นั้นมีหมายเลข OID เท่ากับ 1.3.6.1.2 ตามมาตรฐาน ดังนั้นโหนดหรือซับทรี mib-2 ก็จะมีหมายเลข OID เท่ากับ 1.3.6.1.2.1 ซึ่งเป็นไปตามหลักการ จะพบว่าภายใต้โหนด mib-2 ก็จะอีกมีหลายหลายโหนด แต่ที่จะยกตัวอย่าง หรือ เน้น นั้นคือโหนด interfaces ซึ่งถูกนิยามโดยคำสั่ง { mib-2 2 } และมีหมายเลข OID เท่ากับ 1.3.6.1.2.1.2
จะพบว่าหลังจากที่ชื่อ OID ได้ถูกนิยาม เราจะต้องนิยามในรายละเอียดของออปเจ็กต์นั้นจริง ๆ ทุกทุกการนิยามของออปเจ็กต์จะมีรูปแบบดังต่อไปนี้
<name> OBJECT-TYPE
SYNTAX <datatype>
ACCESS <either read-only, read-write, write-only, or not-accessible>
STATUS <either mandatory, optional, or obsolete>
DESCRIPTION
“Textual description describing this particular managed object.”
::= { <Unique OID that defines this object>}
จากตัวอย่าง ออปเจ็กต์แรกที่ถูกนิยามในไฟล์ mib ดังกล่าวคือ ifTable ที่จะใช้จัดกลุ่มของอินเตอร์เฟซของอุปกรณ์ที่ถูกจัดการให้อยู่ในรูปแบบของตาราง การตั้งชื่อสามารถตั้งชื่อออปเจ็กต์โดยใช้อักษรตัวเล็กตัวใหญ่ผสมกันได้แต่ตัวแรกต้องเป็นตัวเล็กเสมอซึ่งการนิยามตามมาตรฐาน ASN.1 ที่สำคัญที่ต้องจดจำ ดังตัวอย่างของล่าง
ifTable OBJECT-TYPE
SYNTAX SEQUENCE OF IfEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
“A list or interface entries. The number of entries is given by
The value of ifNumber.”
::= {interfaces 2}
รูปแบบซินเท็กซ์ของ ifTable คือ SEQUENCE OF IfEntry หรือเป็นตารางของ แถวลำดับข้อมูล IfEntry ที่ประกอบด้วยหลายชนิดข้อมูล นั้นหมายความว่า ifTable จะทำหน้าที่เป็นตารางที่ประกอบด้วยคอลัมน์ข้อมูลที่ถูกนิยามในออปเจ็กต์ IfEntry ตัวออปเจ็กต์ ifTable นั้นเป็นเพียงการจัดกลุ่มดังนั้นจึงสามารถกำหนดการเข้าถึงให้เป็นแบบ not-accessible ที่หมายความว่าไม่สามารถร้องขอข้อมูลของออปเจ็กต์นี้จากตัวเอเยนต์ได้เนื่องจากไม่มีข้อมูลที่สำคัญ สำหรับสถานะความจำเป็นของออปเจ็กต์ตัวอย่างจะเป็นแบบ mandatory นั้นหมายความว่าเอเยนต์ต้องมีการสร้างออปเจ็กต์นี้เพื่อจะได้ตรงตามข้อกำหนดของ MIB-II ในส่วนของ DESCRIPTION จะใช้อธิบายความหมายเพิ่มเติมของออปเจ็กต์นั้นนั้น สำหรับตัวอย่างนี้หมายเลข OID ของตารางอินเตอร์เฟซ คือ 1.3.6.1.2.1.2.2 หรือ iso.org.dod.internet.mgmt.interfaces.2
คราวนี้เรามาดูคำสั่งที่สำคัญอีกคำสั่งนั้นคือ SEQUENCE ที่ถูกใช้เพื่ออธิบายแถวลำดับของข้อมูลดังที่กล่าวมาแล้วข้างต้น ดังต่อไปนี้
IfEntry ::=
SEQUENCE {
ifIndex
INTEGER,
ifDescr
DisplayString,
ifType
INTEGER,
ifMtu
INTEGER,
.
.
ifSpecific
OBJECT INDENTIFIER }
จดจำไว้ว่าชื่อของ sequence หรือแถวลำดับข้อมูล เช่น IfEntry สามารถผสมตัวเล็กตัวใหญ่ได้เช่นกัน แต่ตัวแรกของชื่อต้องเป็นตัวใหญ่เท่านั้นซึ่งแตกต่างจากการนิยามออปเจ็กต์ทั่วไป เช่น ifTable และตัวอย่างข้างต้นคือการนิยาม Sequence ซึ่งอันที่ที่จริงแล้วจะพบว่า Sequence เป็นเพียงรายการของออปเจ็กต์ในลักษณะคอลัมน์ที่ถูกนิยามตามชนิดของข้อมูลมาตรฐาน SMI ในตัวอย่างดังกล่าว เราสามารถตรวจสอบชนิดข้อมูลของออปเจ็กต์ต่าง ๆ เช่น ifIndex, ifDescr, ifType เป็นต้น จากการสร้างออปเจ็กต์ที่ไว้จัดกลุ่มข้อมูลในลักษณะตารางนี้ทำสามารถบรรจุในลักษณะแถวหรือ โรว์ (row) ที่สามารถบรรจุข้อมูลประเภทเดียวกันจำนวนหลายหลายโรว์ ขึ้นอยู่กับความสามารถ หรือประสิทธิภาพของตัวเอเยนต์ หรืออุปกรณ์จริง ๆ
ตอนนี้เราได้สร้าง ifEntry ที่เป็น Sequence เพื่อใช้ในการกำหนดว่ามีข้อมูลอะไรบ้างในแต่ละโรว์ของตาราง ดังนั้นต่อไปมาดูการนิยามของออปเจ็กต์ ifEntry ที่เป็นข้อมูลจริง ๆ หรือแทนคุณสมบัติจริงของอุปกรณ์ในแต่ละโรว์ ได้ดังต่อไปนี้
ifEntry OBJECT-TYPE
SYNTAX IfEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
“An interface entry containing objects at the subnetwork layer
And below for a particular interface.”
INDEX {ifIndex}
::= {ifTable 1}
ifEntry เป็นการนิยามโรว์ในตาราง ifTable การนิยามโรว์นี้จะสามารถทำให้เป็นเอกลักษณ์ได้โดยใช้เงื่อนไข clause คำว่า INDEX ค่าของอินเด็กซ์จะเป็นค่าที่ไม่ซ้ำกันเพื่อใช้จำแนกแต่ละโรว์ในตาราง ifTable แต่อย่างไรก็ตามก็ขึ้นอยู่กับตัวเอเยนต์ที่ต้องตรวจสอบค่าอินเด็กซ์ไม่ให้ซ้ำกัน เช่นกัน ถ้าเราเตอร์มีจำนวน 6 อินเตอร์เฟซ ในตาราง ifTable จะมี 6 โรว์ของ ifEntry แล้วแต่ละ ifEntry จะมีหมายเลข OID เท่ากับ 1.3.6.1.2.1.2.2.1 หรือ iso.org.dod.internet.mgmt.interfaces.ifTable.ifEntry ตามด้วยตัวอินเด็กซ์ของ ifEntry จะเป็นหมายเลขต่อท้ายถัดไป การนิยาม ifIndex จะถูกนิยามดังต่อไปนี้
ifIndex OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
“A unique value for each interface. Its value ranges between
1 and the value of ifNumber. The value for each interface
must remain constant at leaset from on reinitialization of the
entity’s network-management system to the next reinitialization.”
::= {ifEntry 1}
ข้อมูลของออปเจ็กต์ ifIndex จะอ่านได้เพียงอย่างเดียวนั้นมีความหมายว่าเราจะเห็นค่าออกมาแต่ไม่สามารถจะเปลี่ยนแปลงค่าได้ ส่วนออปเจ็กต์สุดท้ายทีจะกล่าวเพียงเล็กน้อยในการนิยามในไฟล์ MIB คือ ifDescr ซึ่งเป็นข้อความสำหรับอธิบายความหมายเพิ่มเติมในแต่ละโรว์ สุดท้ายในแต่ละไฟล์ MIB จะต้องจบด้วยคำสั่ง END ที่เป็นตัวบ่งบอกให้ตัวคอมไพเลอร์ถึงตำแหน่งจบของข้อมูลไฟล์ MIB
ในตอนที่ 3 ตอนถัดไป จะกล่าวถึงรายละเอียดในแต่ SNMPv2 ที่มีคุณสมบัติเพิ่มเติม และถูกนิยามตามโครงสร้าง SMIv2 โปรดติดตามนะครับ
เอกสารอ้างอิง
1. Subramanian, Mani. Network Management. Addison-Wesley, 2000
2. Stallings, W. SNMP, SNMPv1, SNMPv3 and RMON 1 and 2. Addison-Wesley, 1999
3. Douglas Mauro, Kevin Schmidt. Essential SNMP. O’Reilly, 2001
4. IETF SNMPv3 working group (Web sites).
5. Andrew Tanenbaum, Computer Networks (fourth edition), Prentice Hall, Upper Saddle River, NJ, 2003, ISBN 0-13-038488-7.
สงวนลิขสิทธิ์ ตามพระราชบัญญัติลิขสิทธิ์ พ.ศ. 2539 www.thailandindustry.com
Copyright (C) 2009 www.thailandindustry.com All rights reserved.
ขอสงวนสิทธิ์ ข้อมูล เนื้อหา บทความ และรูปภาพ (ในส่วนที่ทำขึ้นเอง) ทั้งหมดที่ปรากฎอยู่ในเว็บไซต์ www.thailandindustry.com ห้ามมิให้บุคคลใด คัดลอก หรือ ทำสำเนา หรือ ดัดแปลง ข้อความหรือบทความใดๆ ของเว็บไซต์ หากผู้ใดละเมิด ไม่ว่าการลอกเลียน หรือนำส่วนหนึ่งส่วนใดของบทความนี้ไปใช้ ดัดแปลง โดยไม่ได้รับอนุญาตเป็นลายลักษณ์อักษร จะถูกดำเนินคดี ตามที่กฏหมายบัญญัติไว้สูงสุด
Thailandindustrycom_official
