Simple Network Management Protocol
Network Manajemen
Salah satu pekerjaan yang mungkin paling sulit untuk dilakukan adalah mengatur / memanaged banyak peralatan jaringan, seperti, router, gateway, server dll. Alangkah indahnya, jika proses manajemen peralatan jaringan dapat dilakukan dengan mudah dari satu komputer tanpa perlu secara fisik mengkonfigurasi di muka masing-masing alat satu per satu.
Untuk keperluan tersebut, di kembangkan Simple Network Management Protocol (SNMP) yang merupakan bagian dari keluarga protokol Internet yang di definisikan oleh Internet Engineering Task Force (IETF).
SNMP adalah protokol populer untuk melakukan network manajemen. SNMP digunakan untuk mengumpulkan informasi, dan mengkonfigurasi, peralatan jaringan, seperti, server, printer, hub, switch, dan router di jaringan berbasis Internet Protocol (IP). SNMP dapat mengumpulkan informasi seperti kondisi CPU, temperatur chasis, dan hampir tidak ada batas akan apa yang dapat dikonfigurasi oleh SNMP.
Protokol SNMP di rancang untuk memberikan metoda “sederhana” untuk memanage jaringan TCP/IP secara terpusat. Jika anda ingin memanaged peralatan dari komputer pusat, protokol SNMP akan memfasilitasi transfer data dari sisi client sampai sisi server dimana data secara terpusat di catat, di lihat dan di analisa. SNMP tersediri dari sekumpulan standard manajemen jaringan, termasuk di dalamnya definisi aplikasi di lapisan aplikasi, schema database dan sekumpulan objek data. Tujuan utama dari protokol SNMP hanya pada satu tujuan saja, dan masih digunakan hingga hari ini, yaitu, melakukan remote manajemen dari peralatan. SNMP banyak digunakan untuk memanage peralatan di jaringan komputer.
CP/IP Internet Standard Management Framework Architecture and Protocol Components (Page 1 of 2) TCP/IP network management is based on the Simple Network Management Protocol, abbreviated SNMP. As we saw in the overview topic, however, this term is ambiguous. While it is commonly used to refer to the actual communication protocol used to exchange network management information, the term also refers to the entire set of technologies that enable TCP/IP network management. The technical name for this larger architecture is the Internet Standard Management Framework. Again, even though it may seem strange, this term is actually abbreviated in the standards as “SNMP”. For simplicity, I abbreviate it as the “SNMP Framework”, to differentiate it from the SNMP protocol. he Internet Standard Management Framework encompasses all of the technologies that comprise the TCP/IP network management solution. The SNMP Framework consists of a number of architectural components that define how management information is structured, how it is stored, and how it is exchanged using the SNMP protocol. The Framework also describes how the different components fit together, how SNMP is to be implemented in network devices, and how the devices interact. As we will explore in more detail later, the Internet Standard Management Framework is entirely information-oriented. It includes the following primary components (see Figure 271): Structure of Management Information (SMI): To ensure interoperability of various devices, we want to have a consistent way of describing the characteristics of devices to be managed using SNMP. In computer science, a data description language (DDL) is the tool for this job. The Structure of Management Information (SMI) is a standard that defines the structure, syntax and characteristics of management information in SNMP. Management Information Bases (MIBs): Each managed device contains a set of variables that is used to manage it. These variables represent information about the operation of the device that is sent to a network management station, and/or parameters sent to the managed device to control it. The management information base (MIB) is the full set of these variables that describe the management characteristics of a particular type of device.
Each variable in a MIB is called a MIB object, and is defined using the SMI data description language. A device may have many objects, corresponding to the different hardware and software elements it contains. Initially, a single document defined the MIB for SNMP, but this model was inflexible. To allow new MIB objects to be more easily defined, groups of related MIB objects are now defined in separate RFC standards called MIB modules. Over 100 such MIB modules have been defined so far. Simple Network Management Protocol (SNMP): This is the actual SNMP protocol itself. It defines how information is exchanged between SNMP agents and network management stations. The SNMP protocol operations define the various SNMP messages and how they are created and used. SNMP transport mappings describe how SNMP can be used over various underlying internetworks, such as TCP/IP, IPX and others. Security and Administration: To the three main architectural components above, the SNMP Framework adds a number of supporting elements. These provide enhancements to the operation of the SNMP protocol for security, and address issues related to SNMP implementation, version transition and other administrative issues.
Figure 271: Components of the TCP/IP Internet Standard Management Framework
TCP/IP Structure of Management Information (SMI) and Management Information Bases (MIBs) Overview (Page 1 of 3)
The key to really understanding TCP/IP network management is to comprehend the information-oriented nature of the entire Internet Standard Management Framework (SNMP Framework). To see what I mean by this, let's step back for a moment and consider in general terms the problem of network management, and more specifically, the problem of managing devices on a network. Understanding SNMP's Information-Oriented Design
A network administrator needs to perform two basic types of actions: gather data about devices to learn how they are functioning, and give commands to devices to change how they are functioning. In the simplest terms, the first category can be considered like a “read” operation, and the second is comparable to a “write” operation.
A classical way of implementing this functionality is to define a communication protocol. Most such protocols are command-oriented—they consist of a specific set of commands to perform the “read” and “write” operations we mentioned above. For example, a network management protocol might have a read command such as “report on number of hours device has been in use”, and a write command such as “put this device into test mode”. The network manager would control the device by giving the appropriate commands.
A command-oriented management protocol has the advantage of simplicity: it's clear what the commands are for and how they are to be used. It can be reasonably well-suited for use in certain environments, but it doesn't work well on a large, heterogeneous TCP/IP internetwork. The main reason for this is that command-orientation inextricably ties the protocol to the devices being managed. Consider:
* Every type of device might require a distinct set of commands. For example, the commands given to a router might need to be different than those given to a host. This would lead either to a proliferation of commands in the protocol, or to inflexibility in allowing proper management of different device types.
* Every time a company created a new type of device, or made a unique version of a type of device, the network management protocol would have to be changed.
* Whenever the operation of a kind of device changed, due perhaps to a change in another protocol, the management protocol would need to be updated.
* The protocol itself could not be easily changed without affecting a lot of hardware.The solution to the problems of command-oriented management protocols was to use an information-oriented model. Instead of defining specific commands that interrogate or control devices, the devices are defined in terms of units of information that are to be exchanged between the devices and a management station.
Instead of “read” commands and “write” commands, we have variables that can be “read” or “written”. Take the two examples mentioned earlier. Instead of a command like “report on a number of hours device has been in use”, the device keeps a variable called “number of hours in use” and the network management station can “read” this as one of many variables, with no need for a specific protocol command. Instead of a “write” command called “put this device into test mode”, the device has a variable called “current mode”. The network manager can change the mode of the device to “test” by changing the value of the variable.
This difference may seem subtle, but it in fact underlies every aspect of how SNMP works. I believe part of why the SNMP Framework is hard to understand is because insufficient emphasis is placed on looking at things in the “SNMP way”, which means thinking about information objects and not commands.
Key Concept: Unlike most protocols, which are command-oriented, SNMP is information-oriented. SNMP operations are implemented using objects called variables that are maintained in managed devices. Rather than issuing commands, a network management station checks the status of a device by reading variables, and controls the operation of the device by changing (writing) variables.
SNMP menggunakan UDP
UDP singkatan dari User Datagram Protocol dan merupakan kebalikan dari TCP, Transmission Control Protocol yang sangat reliable dan protokol dengan overhead waktu yang tinggi.
User Datagram Protocol sangat rendah overhead-nya, cepat dan tidak reliabel.UDP di definisikan di RFC 768. UDP lebih mudah di gunakan daripada menggunakan protokol yang lebih kompleks seperti TCP. Walau demikian, UDP mampu memberikan banyak fungsi yang memungkinkan komputer pusat manajemen untuk berkomunikasi dengan agen remote yang terdapat pada managed device. Unreliabilitas dapat di kompensasi dengan menggunakan proses cek-and-recek, sementara pada TCP selalu di tunggu paket acknowlege. Sementara yang terjadi dalam pencatatan di peralatan biasanya pada siklus waktu periodik, tidak masalah jika ada data yang hilang karena nantinya akan tetap di update dengan data yang baru. Hal lain yang menyebabkan UDP menarik untuk digunakan adalah karena sangat sederhana, tidak memakan bandwidth jaringan terlalu besar tidak seperti TCP.
Operasi SNMP
Rancangan SNMP relatif sederhana. Pada dasarnya ada dua (2) pemain utama di SNMP, yaitu, manager dan agen. Manager biasa berupa komputer utama, seperti, HP OpenView. Agen dapat berupa software SNMP yang berjalan di client yang berusaha kita monitor.
Manager biasanya berupa software aplikasi yang berjalan di sebuah workstation atau komputer besar yang berkomunikasi dengan agen yang berjalan di setiap peralatan yang akan di monitor. Agen dapat di temukan di switch, firewall, server, wireless access point, router, hub, bahkan di user workstation. Manager akan meminta agen akan informasi, dan agen akan menjawab dengan informasi yang di inginkan.
Network Management Station (NMS)
The manager is also called a Network Management Station or NMS for short. The software used to create the NMS varies in functionality as well as expense. You can get cheaper applications with lesser functionality or pay through the nose and get the Lamborghini of NMS systems. Other functionalities of the NMS include reporting features, network topology mapping and documenting, tools to allow you to monitor the traffic on your network, and so on. Some management consoles can also produce trend analysis reports. These types of reports can help you do capacity planning and set long-range goals. SNMP Primitives
SNMP has three control primitives that initiate data flow from the requester which is usually the Manager. These would be get, get-next and set. The manager uses the get primitive to get a single piece of information from an agent. You would use get-next if you had more than one item. When the data the manager needs to get from the agent consists of more than one item, this primitive is used to sequentially retrieve data; for example, a table of values. You can use set when you want to set a particular value. The manager can use this primitive to request that the agent running on the remote device set a particular variable to a certain value. There are two control primitives the responder (manager) uses to reply and that is get-response and trap. One is used in response to the requester's direct query (get-response) and the other is an asynchronous response to obtain the requester's attention (trap). As I mentioned earlier, I alluded to the fact that the manager doesn’t always initiate – sometimes the agent can as well. Although SNMP exchanges are usually initiated by the manager software, this primitive can also be used when the agent needs to inform the manager of some important event. This is commonly known and heard of as a ‘trap’ sent by the agent to the NMS.
Management Information Base (MIB)
We just learned what primitives were… the agent and the manager, exchanging data. The data they exchange also has a name. The types of data the agent and manager exchange are defined by a database called the management information base (MIB).The MIB is a virtual information store. Remember, it is a small database of information and it resides on the agent. Information collected by the agent is stored in the MIB. The MIB is precisely defined; the current Internet standard MIB contains more than a thousand objects. Each object in the MIB represents some specific entity on the managed device. SNMPv2 and SNMPv3
Disain SNMP yang di dapat berkembang di mungkinkan karena menggunakan Management Information Bases (MIBs), yang menentukan manajemen data dari subsistem pada peralatan, mengunakan namaspace yang berhirarki yang berisi pengidentifikasi objek, yang di implementasikan melalui ASN.1. Hirarki MIB dapat digambarkan sebagai pohon dengan akar (root) tanpa nama, dengan level / tingkatan yang di tentukan oleh berbagai organisasi. ID MIB Objek pada tingkat / level yang paling tinggi milik berbagai organisasi standard, sedang ID objek pada level yang lebih rendah dialokasikan oleh organisasi terkait. Model ini mengijinkan manajemen di seluruh lapisan OSI, maupun dikembangkan untuk manajemen aplikasi, seperti, database, email, dan Java. MIB dapat di definisikan untuk informasi dan operasi yang sangat spesifik.
MIB adalah kumpulan informasi yang di atur secara hirarki. MIB di akses menggunakan protokkol network-manajemen seperti SNMP. MIB terdiri dari managed objek dan di identifikasi oleh object identifier (pengidentifikasi objek).
Sebuah managed object, kadang kala di sebut sebagai MIB object, objek, atau MIB, adalah satu dari banyak karakteristik spesifik dari peralatan yang di manaje. Managed object berisi satu atau lebih objek, yang pada dasarnya berupa variabel.
Ada dua (2) jenis managed object yang ada, yaitu,
1.Scalar object, yang mendefinisikan sebuah objek saja. 2.Tabular object (objek tabel), mendefinisikan banyak ibjek terkait yang di kumpulkan dalam tabel MIB.
Sebagai contoh, sebuah managed object – atInput, adalah sebuah scalar object yang berisi satu buah objek kejadian, bernilai bilangan bulat yang mengindikasikan jumlah total paket yang masuk ke sebuah interface jaringan.
Sebuah object identifier (atau object ID atau OID) akan secara unik mengidentifikasi sebuah managed object di hirarki MIB.
Sepintas Abstract Syntax Notation One (ASN.1)
Dalam dunia telekomunikasi dan jaringan komputer, Abstract Syntax Notation One (ASN.1) adalah sebuah standard dan notasi flexibel yang menjelaskan struktur data untuk merepresentasikan, mengenkoding, mengirimkan dan mendekoding data. ASN.1 memberikan aturan formal untuk menjelaskan sebuah struktur objek yang independen / bebas dari teknik enkoding yang spesifik untuk beda mesin dan sangat presisi. Notasi formal ini menghilangkan keragu-raguan.
ASN.1 adalah usaha bersama stanadard ISO dan ITU-T, awalnya di definisikan tahun 1984 sebagai bagian dari CCITT X.409:1984. ASN.1 bergerak membangun standard-nya sendiri, X.208, di tahun 1998 karena banyaknya penggunaan. Kemudian di revisi habis-habisan di tahun 1995 yang di kenal sebagai seri X.680.
Adopsi subset dari ASN.1, Structure of Management Information (SMI), di spesifikasikan sebagai SNMP untuk mendefinisikan kumpulan objek MIB, kumpulan ini biasanya di sebut sebagai MIB modul.
Komponen Dasar SNMP
TCP/IP SNMP Operational Model, Components and Terminology. (Page 1 of 3)
So, it seems the “Simple” Network Management Protocol (SNMP) isn't quite so simple after all. There are many versions and standards and uses of SNMP, and so a lot we need to learn. I think a good place to start in understanding what SNMP does is to look at its model of operation, and examine the components that comprise a TCP/IP network management system and the terminology used to describe them. SNMP Device Types
As we saw in the preceding high-level overview topic, the overall idea behind SNMP is to allow the information needed for network management to be exchanged using TCP/IP. More specifically, the protocol allows a network administrator to make use of a special network device that interacts with other network devices to collect information from them, and modify how they operate. In the simplest sense, then, two different basic types of hardware devices are defined:
* Managed Nodes: Regular nodes on a network that have been equipped with software to allow them to be managed using SNMP. These are, generally speaking, conventional TCP/IP devices; they are also sometimes called managed devices.
* Network Management Station (NMS): A designated network device that runs special software to allow it to manage the regular managed nodes mentioned just above. One or more NMSes must be present on the network, as these devices are the ones that really “run” SNMP.
Sebuah jaringan yang dapat di manage menggunakan SNMP pada dasarnya memiliki tiga (3) komponen, yaitu:
1.Managed Device. 2.Agen. 3.Network-management System (NMS).
Sebuah managed device adalah sebuah node di jaringan yang berisi agen SNMP yang berada di jaringan yang dapat di manage. Managed device akan mengumpulkan dan menyimpan informasi manajemen dan membuat informasi ini tersedia bagi NMS menggunakan SNMP. Managed device, kadang kala di sebut elemen jaringan, dapat berupa router dan akses server, switch dan bridge, hub, host komputer atau printer.
Agen adalah sebuah modul software network manajemen yang berada di dalam managed device. Agen ini mengetahui tentang informasi manajemen dan dalam menterjemahkan ke informasi yang kompatibel dengan SNMP.
Aplikasi NMS menjalankan aplikasi yang dapat memonitor dan mengontrol managed device. NMS memberikan resource memory dan prosesor yang dibutuhkan untuk manajemen network. Satu atau lebih NMS harus ada dalam sebuah jaringan yang di manage.
Arsitektur SNMP
Kerangka SNMP terdiri dari master agen, subagen dan manajemen station
Master Agen Master agen adalah sebuah software yang berjalan di komponen jaringan yang mampu SNMP. Sebagai contoh, sebuah router dapat menjawab permohonan SNMP dari management station. Oleh karenanya sebetulnya berfungsi sebagai server dalam arsitektur client-server atau sebagai daemon dalam terminologi sistem operasi. Sebuah master agen bergantung pada subagen untuk memperoleh oleh informasi manajemen dari sebuah fungsi yang spesifik. Master agen juga sering di sebut sebagai managed object.
Subagen Subagen adalah sebuah software yang yang jalan di komponen jaringan yang mampu SNMP yang mengimplementasikan fungsi untuk informasi dan manajemen seperti di definisikan oleh MIB dari subsistem yang spesifik, contoh Ethernet link layer. Beberapa kemampuan subagen adalah:
Mengumpulkan informasi untuk managed object. Mengkonfigurasi parameter dari managed object. Merespon kepada permintaan / request dari manager. Mengumpulkan tangkapan-tangkapan alarm.
Stasiun Managemen Sebuah stasiun managemen adalah komponen akhir dari arsitektur SNMP. Fungsinya equivalen dengan clent di arsitektur client-server. Stasiun managemen akan mengirimkan request untuk operasi manajemen atas nama administrator jaringan atau aplikasi dan menerima tangkapan dari agen-agen.
Protokol SNMP
Tipe data SNMPv1 dan ASN.1
Pada SNMPv1 SMI di tentukan bahwa semua managed objek mengggunakan subset dari tipe data yang berasosiasi dengan Abstract Syntax Notation One (ASN.1). Tiga (3) tipe data di perlukan untuk ASN.1:
name / nama – sebagai object identifier (object ID). syntax / sintaks – mendefinisikan tipe data dari sebuah objek (contoh, integer atau rangkaian kata-kata). SMI menggunakan subset dari definisi sintaks ASN.1. encoding data – menjelaskan bagaimana managed object di bentuk dalam sebuah untaian data yang di kirimkan lewat jaringan.
Tipe data SNMPv1 dan SMI-Specific
SNMPv1 SMI menentukan penggunakan angka untuk tipe data SMI-specific, yang dibagi dalam dua kategori
Tipe data sederhana Tipe data untuk aplikasi besar
Tiga (3) tipe data sederhana yang di definisikan dalam SNMPv1 SMI, semua mempunyai nilai yang unik,
tipe data integer (bilangan bulat) adalah bilangan bulat dari -2,147,483,648 sampai dengan 2,147,483,647. Oktet string berurutan dari 0 sampai dengan 65,535 oktet. Object ID di set untuk semua object identifier di alokasikan sesuai aturan yang di tulis di ASN.1.
Tujuh tipe data pada aplikasi yang ada di SNMPv1 SMI: network address, counter, gauge, time tick, opaque, integer, dan unsigned integer.
Netwok address mereseprentasikan alamat dari keluar protokol tertentu. SNMPv1 hanya mendukung alamat IP 32-bit. Counter adalah bilangan bulat (integer) non-negatif yang selalu naik sampai mencapai nilai maksimum untuk kemudian kembali ke nol. Pada SNMPv1, besar counter adalah 32-bit. 3.Gauge adalah bilangan bulat non-negarif yang dapat naik atau turun akan menyimpan nilai maximum (atau minimum), seperti di atur di RFC 2578. 4.time tick merepresentasikan waktu seper seratus detik dari sebuah kejadian. 5.Opaque merepresentasikan enkoding bebas yang digunakan untuk menyampaikan informasi dalam bentuk string (kalimat) bebas yang tidak mengikuti tipe data yang ketat yang digunakan oleh SMI. 6.Bilangan bulat (signed integer) merepresentasikan informasi yang bernilai bilangan bulat. Pada ASN.1 ketelitian tipe data ini bebas, pada SMI ketelitian-nya terbatas. 7.Bilangan bulat non-negatif (unsigned integer) mempunyai ketelitian data bebas pada ASN.1, dan ketelitian terbatas pada SMI.
Tabel SNMPv1 MIB
SNMPv1 SMI mendefinisikan tabel yang sangat terstruktur yang digunakan untuk mengumpulkan berbagai kejadian dalam tabel objek (maksudnya objek yang mempunyai banyak variabel). Tabel terdiri dari nol atau lebih baris, yang di index supaya memudahkan SNMP untuk mengambil, mengubah seluruh baris dengan sebuah perintah Get, GetNext atau Set.
SNMPv2 dan Struktur dari Informasi Manajemen
SNMPv2 SMI di jelaskan di RFC 2578. SNMPv2 SMI menambahkan beberapa kondisi dan perbaikan pada tipe data SNMPv1 SMI, seperti, memasukan string bit, network address dan counter. Bit string di definisikan hanya di SNMPv2 an terdiri dari nol atau lebih bit yang menentukan sebuah nilai. Network address merepresentasikan sebuah address dari keluarga protokol tertentu. SNMPv1 hanya mendukung 32-bit IP address, tapi SNMPv2 dapat mendukung tipe pengaddressan lainnya. Counter pada SNMPv1, hanya ada 32-bit counter. Pada SNMPv2, di definisikan counter 32-bit dan 64-bit.
Protokol SNMP bekerja pada lapisan aplikasi. Pada versi 1 mendefinisikan lima (2) inti dari Protocol Data Unit (PDU), yaitu:
GET REQUEST – digunakan untuk mengambil potongan dari informasi manajemen. GET NEXT REQUEST – digunakan secara iteratif untuk mengambil informasi manajemen secara berurut. GET RESPONSE – menggunakan respons agen dengan data untuk mengambil dan menset permohonan dari manager. SET REQUEST – digunakan untuk menginisialisasi dan membuat perubahan nilai pada network elemen. TRAP – digunakan untuk melaporkan sebuah alert atau event yang tidak normal pada subsistem yang di manage. Pada SNMPv1, event yang tidak normal di sebut trap, sementara pada versi SNMP selanjutnya di sebut notifikasi. Pada modul MIB SMIv1, trap di definisikan menggunakan makro TRAP-TYPE; Dalam modul MIB SMIv2, trap di definisikan menggukana makro NOTIFICATION-TYPE.
Beberapa PDU yang di tambahan di versi selanjutnya, termasuk,
GETBULK REQUEST – iterasi yang lebih cepat untuk memperoleh urusan informasi manajemen. INFORM – untuk meng-acknowledge sebuah trap.
Biasanya SNMP menggunakan port UDP 161 untuk agen, dan 162 untuk manager. Manager dapat mengirim Request dari port (source port) mana saja ke port 161 (destination port) di agen. Agen akan merespons balik ke source port di Manager. Manager menerima trap di port 162. Agen dapat mengirimkan trap dari port yang tersedia.
Aturan port di atas belum tentu di gunakan di semua distribusi software SNMP. Beberapa distribusi mengubah nomor port yang digunakan.
Modul Informasi SNMPv2 SMI
SNMPv2 SMI menerangkan modul informasi, yang menjelaskan group dari definisi yang terkait. Ada tiga (3) tipe modul informasi SMI, yaitu, modul MIB, pernyataan compliance , dan pernyataan kemampuan.
Modul MIB berisi definisi dari managed objek yang saling berhubungan. Pernyataan compliance memberikan cara sistematik untuk menjelaskan sebuah group dari managed object yang harus di implementasikan sesuai dengan sebuah standard. Pernyataan kemampuan digunakan untuk memberitahukan secara rinci tingkat kemampuan dukungan sebuah agen terhadap sebuah group MIB. NMS dapat mengatur perilakunya di sesuaikan dengan kemampuan dari pernyataan kemampuan dari agen tersebut.
SNMPv3
Simple Network Management Protocol versi 3 didefinisikan oleh RFC 3411–RFC 3418 (yang juga di kenal sebagai 'STD0062'). Simple Network Management Protocol versi 3 terutama menambahkan keamnan dari konfigurasi remote ke SNMP. SNMPv3 adalah standard SNMP pada saat ini, sejak tahun 2004. IETF menganggap versi yang lama sebagai “Obsolete” atau “Historical”.
SNMPv3 memberikan beberapa fitur keamanan yang penting, seperti,
Integritas message yang menjamin paket tidak di ubah pada saat transit. Authentikasi untuk memverifikasi sumber yang valid dari message. Enkripsi paket untuk mencegah pengintip dari sumber yang tidak di inginkan.
SNMP versi 1
SNMP versi 1 (SNMPv1) adalah implementasi awal dari protokol SNMP. SNMPv1 beroperasi di atas protokol lain, seperti, User Datagram Protocol (UDP), Internet Protocol (IP), OSI Connectionless Network Service (CLNS), AppleTalk Datagram-Delivery Protocol (DDP), dan Novell Internet Packet Exchange (IPX). SNMPv1 banyak digunakan dan menjadi de-facto protokol untuk manajemen jaringan di komunitas Internet.
Beberapa RFC pertama untuk SNMP, yang sekarang di kenal sebagai Simple Network Management Protocol versi 1, muncul di tahun 1998,
RFC 1065 — Structure and identification of management information for TCP/IP-based internets RFC 1066 — Management information base for network management of TCP/IP-based internets RFC 1067 — A simple network management protocol
Protokol di atas, di buat obsolete oleh,
RFC 1155 — Structure and identification of management information for TCP/IP-based internets RFC 1156 — Management information base for network management of TCP/IP-based internets RFC 1157 — A simple network management protocol
Versi 1 di kritik habis-habisan karena lemahnya keamanan. Authentikasi client dilakukan hanya melalui “community string”, yang menjadi password, yang di kirimkan dalam bentuk text biasa. Hal ini terjadi, karena disain di tahun 80-an, authentikasi / security masih di anggap sebagai mimpi dan tidak di sarankan oleh group perancang protokol.
SNMP Versi 2
Versi 2 tidak di adopsi secara luas karena ke tidak sepakatan mengenak kerangka keamanan di dalam standard.
Simple Network Management Protocol versi 2 (RFC 1441–RFC 1452), yang juga di kenal sebagai SNMP v2 atau SNMP v2p, merevisi versi 1 dan memasukan beberapa perbaikan masalah performance, keamanan, kerahasian, dan komunikasi antar manager. SNMP v2 memperkenalkan GETBULK, sebuah alternatif dari iterasi GETNEXT untuk data manajemen dalam jumlah besar melalui satu perintah saja. Akan tetapi, kebanyakan melihatnya terlalu rumit, sehingga tidak secara luas di adopsi.
Community-Based Simple Network Management Protocol version 2, atau SNMP v2c, di definisikan di RFC 1901–RFC 1908. Pada tahap awal, ini di kenal sebagai SNMP v1.5. SNMP v2c yang berisi SNMP v2 tanpa model keamanan kontroversial SNMP v2, tapi menggunakan keamanan berbasis komunitas yang sederhana dari SNMP v1. Walaupun secara resmi lebih dikenal sebagai "Draft Standard", tapi secara de-facto di kenal sebagai standard SNMP v2.
User-Based Simple Network Management Protocol version 2, atau SNMP v2u, di definisikan di RFC 1909–RFC 1910. Ini merupakan usaha untuk memberikan lebih banyak kemampuan keamanan daripada SNMP v1, tanpa memaksakan kerumitan dari SNMP v2. Varian dari ini di dunia komersial di kenal sebagai SNMP v2*, mekanisme yang di kembangkan pada akhirnya di adopsi sebagai salah satu dari dua kerangka keamanan di SNMP v3.
Interoperabilitas SNMPv1 & SNMPv2c
Pada saat di spesifikasikan, SNMPv2 sebetulnya tidak kompatibel dengan SNMPv1 di dua (2) area utama, yaitu, format message dan operasi protokol. Message SNMPv2c menggunakan format header dan protocol data unit (PDU) yang berbeda dengan message SNMPv1. SNMPv2c juga menggunakan dua operasi protokol yang tidak di spesifikasikan di SNMPv1. Oleh karenanya, RFC 1908 mendefinisikan dua (2) kemungkinan strategi agar SNMPv1/v2c dapat bekerjasama, yaitu, proxy agent dan bilingual network-management system.
Proxy Agents SNMPv2 agent dapat berfungsi sebagai proxy untuk managed device dengan SNMPv1, sebagai berikut, NMS SNMPv2 mengirimkan perintah yang ditujukan kepada agen SNMPv1. NMS mengirimkan SNMP message ke agen proxy SNMPv2. Agen proxy mem-forward message Get, GetNext, danSet ke agen SNMPv1 tanpa di ubah. Message GetBulk di konversikan oleh proxy agen menjadi message GetNext yang di forward ke agen SNMPv1. Agen proxy akan memetakan message SNMPv1 trap ke message SNMPv2 trap dan mem-forwardnya ke NMS.
Bilingual Network-Management System Bilingual SNMPv2 network-management system mendukung SNMPv1 dan SNMPv2. Untuk mendukung manajemen dengan dua lingkungan, sebuah aplikasi manajemen di NMS bilingual akan menghubungi agen. NMS dapat mempelajari dari informasi yang di simpan di database lokal untuk menentukan apakah agen tersebut mendukung SNMPv1 atau SNMPv2. Berbasis pada informasi di database NMS akan berkomunikasi dengan agen menggunakan versi SNMP yang cocok.
SNMP versi 3
IETF mengakui Simple Network Management Protocol versi 3 seperti di definisikan oleh RFC 3411–RFC 3418 (juga di kenal sebagai STD0062) sebagai standard SNMP sejak 2004. IETF menganggap versi sebelumnya sebagai “Obsolete" atau "Historical".
Di sisi praktis, implementasi SNMP biasanya memberikan dukungan bagi banyak versi, terutama SNMPv1, SNMPv2c, dan SNMPv3. Ada baiknya membaca RFC 3584 "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework".
SNMPv3 memberikan tiga (3) servis yang penting, yaitu, authentikasi, privasi dan access control.
Contoh Penggunaan Perintah
Monitoring device uptimes (sysUpTimeInstance) Inventory of OS versions (sysDescr) Collect interface information (ifName, ifDescr, ifSpeed, ifType, ifPhysAddr) Measuring network interface throughput (ifInOctets, ifOutOctets) Querying a remote ARP cache (ipNetToMedia)
Beberapa Topik Lain Tentang SNMP
Autodiscovery SNMP secara sederhana sebetulnya merupakan protokol untuk mengumpulkan dan mengatur informasi. Kebanyakan software yang mengimplementasikan SNMP memberikan kemungkinan mekanisme pencarian, menggunakan sebuah koleksi data yang umum untuk semua platform atau peralatan, untuk menarik pengguna baru maupun implementator. Fitur ini banyak digunakan untuk melakukan pencarian secara automatis, jika ada peralatan baru maka akan secara automatis di cek. Untuk SNMPv1 dan SNMPv2c, hal ini berarti resiko keamanan, karena komunitas SNMP read akan terkirim menggunakan text biasa ke peralatan yang menjadi target. Memang di sebuah corporate tertutup keamanan jaringan-nya relatif rendah. Tapi di sebuah datacenter, hosting server, dan fasilitas colocation maka keamanan menjadi sangat fatal.
Efek Negatif Implementasi SNMP akan berbeda-beda di berbagai platform. Pada beberapa kasus, SNMP mungkin di tambahkan fitur yang bukan elemen inti dari disain. SNMP struktur pohon dan index linier yang digunakan tidak selalu cocok dengan struktur data internal dari rancangan dasar sebuah platform. Penggunaan SNMP untuk memperoleh sekumpulan data mungkin akan menyebabkan penggunaan kemampuan CPU yang besar yang berefek negatif terhadap operasi peralatan. salah satu contoh yang paling nyata adalah tabel routing yang besar, seperti, BGP atau IGP.
Pergeseran Index Peralatan modular dapat memberikan nomor ulang jika ada hardware ditambahkan atau diambil. Nilai index biasanya di berikan pada saat boot dan akan tetap sampai boot selanjutnya. Jika hardware ditambahkan pada saat peralatan masih 'hidup' maka index yang diberikan kepada hardware tambahan ini akan berupa nomor terakhir dari index yang ada. Penentuan ulang index hanya akan terjadi pada saat boot selanjutnya, akan tetapi akan menyebabkan pergeseran besar-besaran semua hardware objek karena adanya tambahan objek baru. Jangan kaget kalau terjadi korupsi & ketidakcocokan data dikarenakan adanya perilaku tersebut.
Implikasi Keamanan Versi 1 dan 2C akan sangat rentan terhadap sniffing paket karena string komunitas yang menggunakan text. Karena tidak digunakan challenge-response handshake, semua versi akan sangat rentan terhadap serangan bruteforce dan dictionary attack yang berusaha menebak string komunitas / string authentifikasi. Karena UDP yang digunakan, maka connectionless dan rentan terhadap serangan IP spoofing, semua versi akan rentan terhadap usaha untuk membypass access list yang mungkin sudah di batsi di SNMP access. Memberikan fitur konfigurasi / write (penulisan) yang seringkali kelupaan dari pada fitur yang lebih baik yaitu repoting / read, protokol seringkali lupa / salah konfigurasi sehingga dapat digunakan yang menimbulkan kerusakan. Berdasarkan hasil penelitian SANS Institut, SNMP ternyata menduduki kedudukan paling tinggi karena isu konfigurasi defaut yang menggunakan string komunitas 'public' dan 'private'.
For more detail on SNMP security implications see the CERT SNMP Vulnerabilities FAQ
RFC dan referensi lainnya
[edit] RFCs
* RFC 1155 — Structure and Identification of Management Information for the TCP/IP-based Internets * RFC 1156 — Management Information Base for Network Management of TCP/IP-based internets * RFC 1157 — A Simple Network Management Protocol (SNMP) * RFC 1441 — Introduction to version 2 of the Internet-standard Network Management Framework * RFC 1213 — Management Information Base for Network Management of TCP/IP-based internets: MIB-II * RFC 3410 (Informational) — Introduction and Applicability Statements for Internet Standard Management Framework * RFC 3411 (Standard 62) — An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks * RFC 3412 (Standard 62) — Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) * RFC 3413 (Standard 62) — Simple Network Management Protocol (SNMP) Application * RFC 3414 (Standard 62) — User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) * RFC 3415 (Standard 62) — View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) * RFC 3416 (Standard 62) — Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP) * RFC 3417 (Standard 62) — Transport Mappings for the Simple Network Management Protocol (SNMP) * RFC 3418 (Standard 62) — Management Information Base (MIB) for the Simple Network Management Protocol (SNMP) * RFC 3584 (Best Current Practice) — Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework * RFC 3826 (Proposed) — The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model[edit] See also
* Management information base (MIB) * Object identifier (OID) * Remote monitoring (RMON) * AgentX * Simple Gateway Monitoring Protocol (SGMP) * Common management information protocol (CMIP) * Common management information service (CMIS) * CMIP over TCP/IP (CMOT) * Net-SNMP[edit] External links
* SimpleWeb * Description of the SNMP packet breakdown * SNMP FAQ part 1 * SNMP FAQ part 2[edit] Implementations
* Net-SNMP (Net-SNMP: Open source SNMP implementation) * Netsnmpj: Open source SNMP for Java * OpenSNMP: multi-threaded SNMPv3 engine * PySNMP: pure-Python module, BSD license * TinySNMP: an easy to configure minimal SNMPv1 agent * .SNMPv3 for .NET[edit] References
1. ^ W. Stallings SNMP, SNMPv2, SNMPv3, and RMON 1 and 2 3rd Edition, Addison Wesley, 1998. ISBN 978-0201485349 2. ^ SNMP Version 3 links hub 3. ^ In This Issue: SNMP Version 3 The Simple Times ISSN 1060-6080 4. ^ SNMPv3 CiscoSNMP Version 3 (SNMPv3) Message Format
In the late 1990s, SNMP version 3 was created to resolve the problems that occurred with the many different variations of SNMPv2. The SNMPv3 Framework adopts many components that were created in SNMPv2, including the SNMPv2 protocol operations, PDU types and PDU format. Amongst the significant changes made in SNMPv3 include a more flexible way of defining security methods and parameters, to allow the coexistence of multiple security techniques.
The general message format for SNMPv3 still follows the same idea of an overall message “wrapper” that contains a header and an encapsulated PDU. However, in version 3 this concept is further refined. The fields in the header have themselves been divided into those dealing with security and those that do not deal with security matters. The “non-security” fields are common to all SNMPv3 implementations, while the use of the security fields can be tailored by each SNMPv3 security model, and processed by the module in an SNMP entity that deals with security. This solution provides considerable flexibility while avoiding the problems that plagued SNMPv2.
The overall SNMPv3 message format is described in RFC 3412, which describes version 3 message processing and dispatching. It is shown in Table 221 and Figure 285.
Table 221: SNMP Version 3 (SNMPv3) General Message Format Field Name Syntax Size (bytes) Description Msg Version Integer 4 Message Version Number: Describes the SNMP version number of this message; used for ensuring compatibility between versions. For SNMPv3, this value is 3. Msg ID Integer 4 Message Identifier: A number used to identify an SNMPv3 message and to match response messages to request messages. The use of this field is similar to that of the Request ID field in the PDU format (see Table 218), but they are not identical. This field was created to allow matching at the message processing level regardless of the contents of the PDU, to protect against certain security attacks. Thus, Msg ID and Request ID are used independently. Msg Max Size Integer 4 Maximum Message Size: The maximum size of message that the sender of this message can receive. Minimum value of this field is 484. Msg Flags Octet String 1
Msg Security Model Integer 4 Message Security Model: An integer value indicating which security model was used for this message. For the user-based security model (the default in SNMPv3) this value is 3. Msg Security Parameters — Variable Message Security Parameters: A set of fields that contain parameters required to implement the particular security model used for this message. The contents of this field are specified in each document describing an SNMPv3 security model. For example, the parameters for the user-based model are in RFC 3414. Scoped PDU — Variable
TCP/IP MIB Objects, Object Characteristics and Object Types (Page 1 of 4) The Internet Standard Management Framework (SNMP Framework) is designed to facilitate the exchange of management information. The Management Information Base (MIB) defines a device's management information. The MIB contains a number of variables called MIB objects; they are also called managed objects. These objects are defined according to the rules set out in the Structure of Management Information (SMI) standard. The best place to begin looking at MIB objects is by examining the SMI rules that define them. As I mentioned earlier in this section, two different versions of SMI have been created: SMIv1 as part of the original SNMP, and SMIv2 as part of SNMPv2 and SNMPv3. The two are similar in terms of how MIB objects are described, but SMIv2 allows more information to be associated with each object. Just as a typical protocol uses a field format for specifying the content of messages sent between devices using the protocol, SMI uses a format that specifies the fundamental characteristics of each MIB object. The most basic of these are five mandatory characteristics defined in SMIv1. These are also used in SMIv2, but a couple of names were changed, and the possible values for some of the fields were modified as well. This is shown conceptually in Figure 272.
Figure 272: SNMP Management Information Base (MIB) This diagram shows an SNMP management information base containing “N” MIB objects. Each object has five mandatory characteristics and a variable number of optional characteristics.
Each object has a name that serves to uniquely identify it. Actually, that's not entirely true. Each object actually has two names: a textual name called an Object Descriptor and a numeric Object Identifier that indicates the object's place in the MIB object name hierarchy. I'm sure that made no sense to you, but that's why I included the next topic discussing object naming that hopefully will (make sense that is.)
TCP/IP MIB Object Descriptors and Identifiers and the Object Name Hierarchy and Name Notation (Page 1 of 4)
Of the many MIB object characteristics, only one is sufficiently interesting that it really deserves its own exposition. Or perhaps I should say, only one is sufficiently complicated that it does. J This is the object name, part of the larger naming system used for MIB objects.
As I said before, each MIB object actually has two names: an object descriptor and an object identifier. The object descriptor is a conventional text name that provides a “user-friendly handle” to refer to the object. The name is assigned based on the particular MIB object group in which the object is located. In the example definition I gave at the end of the prior topic, sysLocation is the object descriptor for that MIB object. I describe these names in greater detail in the next topic, on MIB modules and object groups.
TCP/IP MIB Modules and Object Groups (Page 1 of 4)
The Management Information Base (MIB) contains the collection of MIB objects that describe the characteristics of a device using the Internet Standard Management Framework (SNMP Framework). When SNMP was first created, there were not that many objects in the MIB. Furthermore, they were mostly “generic” objects that applied fairly universally to TCP/IP devices as a whole. In fact, most of the MIB objects were variables related to the operation of TCP/IP protocols such as IP, TCP and ICMP.
For this reason, at first, a single document defined “the” Management Information Base (MIB) for SNMP. The first of these documents was RFC 1066, part of the initial SNMPv1 specification. It was then revised in RFC 1156. In RFC 1158, a second version of the MIB, MIB II, was defined, which was essentially the same but made a few changes. The Organization of MIB Objects into Object Groups
The number of MIB objects defined in these standards was relatively small. However, there were still several dozen of them, and it was recognized from the start that more would be created in time. To help organize the objects in a logical way, they were arranged into object groups. These groups serve the purpose of separating the objects and defining how they should be given object identifiers in the overall object name hierarchy.
Each group has associated with it three important pieces of information:
* Group Name: A name that is used as a text label in the object identification tree we saw in the previous topic. These objects are all located within the “iso.org.dod.internet.mgmt.mib” subtree. So for example, the group system would be “iso.org.dod.internet.mgmt.mib.system”.
* Group Number: A number corresponding to the group name used for making numeric identifiers from the object name tree. For example, the group system has the number 1, and so the group's object identifier is 1.3.6.1.2.1.1. All objects in that group will be under that tree; for example, sysUpTime is 1.3.6.1.2.1.1.3.
* Group Code: A text label that may be the same as the group name or may be an abbreviation. It is used as a prefix in making object descriptors (the text names of objects). For example, for the group system the code is sys, and so an object in this group is sysUpTime.
[root@visiongate ~]# service snmpd restart Stopping snmpd: [FAILED] Starting snmpd: [ OK ] [root@visiongate ~]#
Monitoring your system’s web performance can be done quite easily with a number of graphical tools available for Linux. These include MRTG for raw network traffic which is based on SNMP and Webalizer that monitors web site hits. SNMP What is SNMP? Most routers and firewalls keep their operational statistics in Management Information Blocks (MIBs). Each statistic has an Object Identifier (OID) and can be remotely retrieved from the MIB via the Simple Network Management Protocol (SNMP). However, as a security measure, you need to know the SNMP password or "community string" to do so. There are a number of types of community strings, the most commonly used ones are the "Read Only" community string that only provides access for viewing statistics and system parameters. In many cases the "Read Only" community string or password is set to "public". There is also a "Read Write" community string for not only viewing statistics and system parameters but also for updating the parameters too. SNMP on a Linux Server By default, RedHat Linux has the NetSNMP package installed to provide SNMP services. NetSNMP uses a configuration file /etc/snmp/snmpd.conf in which the community strings may be set. The version of the configuration file that comes with Net-SNMP is quite complicated. I suggest archiving it and using a much simpler version with only a single line containing the keyword "rocommunity" followed by the community string. Here is an example of how to do that.
• Save the old configuration file
[root@bigboy snmp]# cd /etc/snmp/ [root@bigboy snmp]# mv snmpd.conf snmpd.conf.old [root@bigboy snmp]# vi snmpd.conf
• Enter the following line in the new configuration file to set the Read Only community string to "craz33guy"
rocommunity craz33guy
• Configure Linux to start SNMP services on each reboot with the chkconfig command:
[root@bigboy root]# chkconfig --level 345 snmpd on [root@bigboy root]#
• You can then start SNMP to load the current configuration file.
[root@bigboy root]# /etc/init.d/snmpd start Starting snmpd: [ OK ] [root@bigboy root]#
• Test whether SNMP can read the "system" and "interface" information MIB
[root@bigboy snmp]# snmpwalk -v 1 -c craz33guy localhost system SNMPv2-MIB::sysDescr.0 = STRING: Linux bigboy 2.4.18-14 #1 Wed Sep 4 11:57:57 EDT 2002 i586 SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10 SNMPv2-MIB::sysUpTime.0 = Timeticks: (425) 0:00:04.25 SNMPv2-MIB::sysContact.0 = STRING: root@localhost SNMPv2-MIB::sysName.0 = STRING: bigboy ... ... ... [root@bigboy snmp]# snmpwalk -v 1 -c craz33guy localhost interface IF-MIB::ifNumber.0 = INTEGER: 3 IF-MIB::ifIndex.1 = INTEGER: 1 IF-MIB::ifIndex.2 = INTEGER: 2 IF-MIB::ifIndex.3 = INTEGER: 3 IF-MIB::ifDescr.1 = STRING: lo IF-MIB::ifDescr.2 = STRING: wlan0 IF-MIB::ifDescr.3 = STRING: eth0 ... ... ... [root@bigboy snmp]#
Note: In this case we were polling localhost. You can poll any SNMP aware network device with SNMP enabled. All you need is the IP address and SNMP read only string and you’ll be able to get similar results. Now that we know SNMP is working correctly on your Linux server, we can configure a SNMP statistics gathering software package such as MRTG to create online graphs of your traffic flows. MRTG What is MRTG? MRTG (Multi Router Traffic Grapher) is a public domain package for producing graphs of various types of router statistics via a web page. You can easily create graphs of traffic flow statistics through your home network's firewall / router or even your Linux box's NIC cards using MRTG. The product is available from the MRTG website and also on your distribution CDs. Download and Install The MRTG Packages Most RedHat Linux software products are available in the RPM format. Downloading and installing RPMs isn’t hard. If you need a refresher, the chapter on RPMs covers how to do this in detail. The latest version of the RPM for RedHat 8.0 is:
mrtg-2.9.17-8.i386.rpm
o You can install the package like this:
[root@bigboy tmp]# rpm -Uvh mrtg-2.9.17-8.i386.rpm
o You will also need to have a webserver package installed for MRTG to work. The RedHat RPM version seems to work with Apache 1.X. The most current version as of this writing was apache 1.3.23 - 11. This is available from the RedHat website or your installation CDs. Install apache using the following command.
[root@bigboy tmp]# rpm -Uvh apache-1.3.23-14.i386.rpmo MRTG runs automatically upon startup, but you’ll need to configure Apache to start at boot using the chkconfig command:
[root@bigboy tmp]# chkconfig --level 35 httpd on
o Here’s how to start/stop/restart Apache after booting:
[root@bigboy tmp]# /etc/init.d/httpd start [root@bigboy tmp]# /etc/init.d/httpd stop [root@bigboy tmp]# /etc/init.d/httpd restart
By default Apache expects the HTML files for your website to be located in /var/www/html. MRTG will place its HTML files in /var/www/html/mrtg.
Configuring MRTG By default, MRTG will map the inbound and outbound data throughput rates on the device it is polling. There are ways to specify other OIDs such as CPU and memory usage, but this is beyond the scope of this book. We’ll be discussing the default configuration. When the MRTG RPM is installed it creates a directory called /etc/mrtg in which all future configuration files are stored. Here are the steps you need to go through to create new configuration files.
o In this example we'll use MRTG’s cfgmaker command to create a configuration file named localhost.cfg for the server "bigboy" using a read only community string of craz33guy. All data files will be placed in the directory /var/www/html/mrtg/stats.
[root@bigboy tmp]# cfgmaker --output=/etc/mrtg/localhost.cfg \ -ifref=ip --global "workdir: /var/www/html/mrtg/stats" \ craz33guy@localhost
--base: Get Device Info on craz33guy@localhost: --base: Vendor Id: --base: Populating confcache --snpo: confcache craz33guy@localhost: Descr lo --> 1 --snpo: confcache craz33guy@localhost: Descr wlan0 --> 2 --snpo: confcache craz33guy@localhost: Descr eth0 --> 3 --snpo: confcache craz33guy@localhost: Ip 0.0.0.0 --> 3 --snpo: confcache craz33guy@localhost: Ip 127.0.0.1 --> 1 --snpo: confcache craz33guy@localhost: Ip 192.168.1.100 --> 2 --snpo: confcache craz33guy@localhost: Type 24 --> 1 --snpo: confcache craz33guy@localhost: Type 6 --> 2 --snpo: confcache craz33guy@localhost: Type 6 --> 3 (duplicate) --snpo: confcache craz33guy@localhost: Eth --> 1 --snpo: confcache craz33guy@localhost: Eth 00-06-25-09-6a-b5 --> 2 --snpo: confcache craz33guy@localhost: Eth 00-08-c7-10-74-a8 --> 3 --base: Get Interface Info --base: Walking ifIndex --base: Walking ifType --base: Walking ifSpeed --base: Walking ifAdminStatus --base: Walking ifOperStatus --base: Writing /etc/mrtg/localhost.cfg [root@bigboy tmp]#
o Next create the /var/www/html/mrtg/stats directory and copy all of MRTG’s standard “.png” image files into it.
[root@bigboy mrtg]# mkdir /var/www/html/mrtg/stats [root@bigboy mrtg]# cp /var/www/html/mrtg/*.png /var/www/html/mrtg/stats [root@bigboy mrtg]#
o Edit /etc/mrtg/localhost.cfg and remove the sections related to interfaces you don't need to monitor. This would most likely include the loopback interface L0: with the IP address of 127.0.0.1 When the MRTG RPM is installed it places an entry in the /etc/crontab file to make MRTG run every 5 minutes using the default /etc/mrtg/mrtg.cfg configuration file. Add a new line referring to /etc/mrtg/localhost.cfg and comment out the one pointing to mrtg.cfg.
- 0-59/5 * * * * root /usr/bin/mrtg /etc/mrtg/mrtg.cfg
o Run MRTG using /etc/mrtg/localhost.cfg as your argument three times. You'll get an error the two times as MRTG tries to rename old data files, and naturally, the first time it is run, MRTG has no data files to move.
[root@bigboy mrtg]# mrtg /etc/mrtg/localhost.cfg Rateup WARNING: /usr/bin/rateup could not read the primary log file for localhost_192.168.1.100 Rateup WARNING: /usr/bin/rateup The backup log file for localhost_192.168.1.100 was invalid as well Rateup WARNING: /usr/bin/rateup Can't remove localhost_192.168.1.100.old updating log file Rateup WARNING: /usr/bin/rateup Can't rename localhost_192.168.1.100.log to localhost_192.168.1.100.old updating log file [root@bigboy mrtg]# mrtg /etc/mrtg/localhost.cfg Rateup WARNING: /usr/bin/rateup Can't remove localhost_192.168.1.100.old updating log file [root@bigboy mrtg]# mrtg /etc/mrtg/localhost.cfg [root@bigboy mrtg]#
o You'll then want to use MRTG’s indexmaker command to create a combined index page to see all the graphs defined in all the various “.cfg” files in your /etc/mrtg directory. Once this is done, you can point your browser to http://ip-address/mrtg/ to get a graphical listing of all the monitored interfaces. Note: The indexmaker command creates a very generic index page which is very similar to the MRTG home page, don’t be fooled, you will find your devices at the very bottom. The format of the command is:
indexmaker --output=filename device1.cfg device2.cfg etc
RedHat Version 8.0 and Indexmaker RedHat version 8 gives an error like this when running indexmaker.
[root@bigboy mrtg]# indexmaker --output=index.html /etc/mrtg/localhost.cfg Can't locate package $VERSION for @MRTG_lib::ISA at /usr/bin/indexmaker line 49 main::BEGIN() called at /usr/bin/../lib/mrtg2/MRTG_lib.pm line 49 eval {...} called at /usr/bin/../lib/mrtg2/MRTG_lib.pm line 49 [root@bigboy mrtg]#
You have a couple choices here: • Run a version of indexmaker from an older version of RedHat • Create your own custom index page to replace the default one in /var/www/html/mrtg. You can then add links to all the html files in the /var/www/html/mrtg/stats directory. Using MRTG To Monitor Other Subsystems MRTG will generate HTML pages with daily, weekly, monthly and yearly statistics for your interfaces. By default MRTG provides only network interface statistics. The MRTG website www.mrtg.org has links to other sites that show you how to monitor other sub-systems on a variety of devices and operating systems. Webalizer What Is Webalizer? Webalizer is a web server log file analysis tool that comes installed by default on RedHat Linux. Each night, Webalizer reads your Apache log files and creates a set of web pages that allow you to view websurfer statistics for your site. The information provided includes a list of your web site’s most popular pages sorted by “hits” along with traffic graphs showing the times of day when your site is most popular. How To View Your Webalizer Statistics By default webalizer places its index page in the directory /var/www/html/usage, so if you have a default Apache installation you’ll be able to view your data by visiting http://www.my-site.com/usage The Webalizer Configuration File Webalizer stores its configuration in the file /etc/webalizer.conf. The default settings should be sufficient for your web server, but you may want to adjust the directory in which Webalizer places your graphic statistics. This can be adjusted with the OutputDir directive in the file. Make Webalizer run in Quiet Mode Webalizer has a tendency to create this message in your logs which according to the Webalizer site’s documentation is non-critical.
Error: Unable to open DNS cache file /var/lib/webalizer/dns_cache.db
You can make the software run in quite mode by editing the /etc/cron.daily/00webalizer script file and adding the –Q (Quiet) switch to the webalizer command like this:
- ! /bin/bash
- update access statistics for the web site
/usr/bin/webalizer -Qfi
exit 0
Once you’ve done this, Webalizer will function with few annoyances, however be aware that running in quiet mode could hide deeper problems that could occur in future.
