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 Cisco
SNMP 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.rpm
o 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
0-59/5 * * * * root /usr/bin/mrtg /etc/mrtg/localhost.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
if [ -s /var/log/httpd/access_log ] ; then
/usr/bin/webalizer -Q
fi
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.
Definisi: Ethernet adalah perangkat fisik teknologi dan data link layer untuk jaringan area lokal
(LAN).Ethernet diciptakan oleh insinyur Robert Metcalfe. Pertama kali
banyak digunakan pada tahun 1980, Ethernet mendukung kecepatan data
teoritis maksimal 10 megabits per detik (Mbps). Kemudian, apa yang
disebut “Fast Ethernet” standar laju data meningkat maksimum sampai 100
Mbps. Saat ini, teknologi Gigabit Ethernet lebih meluas dan kinerja
puncaknya sampai dengan 1000 Mbps.
