ZEBRA GNU Dinamik Routing
ZEBRA GNU Dinamik Routing
perhatian : tulisan ini hanya untuk network-enginer
the story begin...
Bagi seorang admin jaringan, tentu sudah tidak asing lagi dengan istilah router. Router adalah perangkat yang digunakan untuk menghubungkan 2 buah network yang berbeda. Bekerja menggunakan prinsip layer 3 pada OSI layer.Banyak sudah vendor perangkat yang membuat device router, semisal cisco©, 3com©, dlink© dan lain-lain©. Hanya saja harga yang ditawarkan cukup mahal, bisa dalam bilangan belasan hingga puluhan juta rupiah. Bagi perusahaan menengah dengan banyak network tentu akan berpikir berlipat-lipat kali untuk membeli banyak router.
Beberapa solusi yang dapat dipakai adalah dengan :
- statik routing
statik routing didukung oleh beberapa OS, seperti Linux© atau-pun MS Windows™, tanpa menambahkan aplikasi tertentu.
pemakaian statik routing akan menjadi solusi yang mudah dan cepat untuk network dengan jumlah sub/network sedikit. Bila jaringan sudah menjadi lebih besar dan kompleks, statik routing menjadi masalah baru bagi admin jaringan - aplikasi zebra
Aplikasi zebra dapat dipasangkan diatas sistem operasi berbasis unix, semisal linux atau bsd.
Zebra menawarkan solusi dinamik routing. Dinamik routing memungkinkan seorang admin jaringan menata berbagai network tanpa kesulitan lagi.
Dengan dukungan open standart, maka zebra dapat berkomunikasi dengan router hardware seperti cisco©, 3com© dan lain-lain©, dengan menggunakan open standar dinamik routing semisal rip, ospf, is-is, bgp.
Kompilasi
Library PendukungZebra membutuhkan library readline untuk dapat menggunakan fasilitas vty. Vty dipakai agar dapat telnet dan mengkonfigur zebra seperti halnya konfigur di cisco.
library ini dapat diambil dari ftp://ftp.gnu.org/gnu/readline/
root@opera root# tar xzpf readline-4.3.tar.gz
root@opera root# cd readline-4.3
root@opera readline-4.3# ./configure
root@opera readline-4.3# make
root@opera readline-4.3# make install
ZEBRA
Konfigurasi dilakukan pada linux Trustix 2.0. Source zebra dapat diambil dari www.zebra.org.
versi terbaru pada saat artikel dibuat adalah 0.94
step-step kompilasi zebra
- extrax file tar.gz
root@opera root# tar xzpf zebra-0.94.tar.gz
root@opera root# cd zebra-0.94 - konfigurasi zebra, dukungan ipv6 dimatikan, tambahkan fasilitas vty dan tpc-zebra, dan lalukan kompilasi
root@opera zebra-0.94# ./configure --sysconfdir=/etc/zebra \
--disable-ipv6 \
--enable-tcp-zebra \
--enable-vtysh
root@opera zebra-0.94# make
root@opera zebra-0.94# make install - Siapkan file initd agar bisa menjalankan zebra otomatis pada saat booting setelah ini selesai anda masih harus mengedit file satu persatu untuk menyesuaikan letak dari file.
root@opera zebra-0.94# cp init/redhat/zebra.init /etc/init.d/zebra
root@opera zebra-0.94# cp init/redhat/ripd.init /etc/init.d/ripd
root@opera zebra-0.94# cp init/redhat/ospfd.init /etc/init.d/ospfd
root@opera zebra-0.94# cp init/redhat/bgpd.init /etc/init.d/bgpd
root@opera zebra-0.94# chmod 755 /etc/init.d/*baris 10/usr/sbin menjadi /usr/local/sbin
baris 14[ -f /etc/xxxxx.conf ] menjadi [ -f /etc/zebra/xxxxx.conf ]
baris 19. /etc/rc.d/init.d/functions menjadi . /etc/init.d/functions
- siapkan file konfigurasi yang terletak dengan menghilangkan extensi sample di /etc/zebra
root@opera zebra-0.94# cd /etc/zebra
root@opera zebra# mv zebra.conf.sample zebra.conf
root@opera zebra# mv ripd.conf.sample ripd.conf
root@opera zebra# mv osfpd.conf.sample ospfd.conf
root@opera zebra# mv bgpd.conf.sample bgpd.conf - tambahkan baris berikut pada file /etc/services
root@opera zebra# vi /etc/services
zebrasrv 2600/tcp
zebra 2601/tcp
ripd 2602/tcp
ripng 2603/tcp
ospfd 2604/tcp
bgpd 2605/tcp
ospf6d 2606/tcp - sampai pada tahap ini zebra sudah siap untuk dioperasikan.
perlu diperhatikan aplikasi dinamik routing di zebra bersifat modular, setiap routing mempunyai binary sendiri-sendiri. Tetapi semua binari zebra membutuhkan daemon zebra untuk dapat bekerja.
Bila ingin menjalankan routing rip, maka yang diaktifkan adalahcek koneksi dari netstat, bila berjalan zebra akan membuka port 2600 tcp dan 2601 tcp,root@opera root# service zebra start
root@opera root# service ripd start
ripd akan membuka port 2602 tcp dan 520 udp.root@opera root# netstat -tuan
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 127.0.0.1:2600 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:2601 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:2602 0.0.0.0:* LISTEN
udp 0 0 0.0.0.0:520 0.0.0.0:*
- Ahmad Sofyan : 07.0511.0006
- Agus Budi Prasetyo : 07.511.0005
- Atkh Solikin : 07.0511.0150
- Nur Arif Mustofa : 07.0511.0079
- Achmad Rudiyanto : 07.0511.0139
Tugas Jarkom OSPF
OSPF-2 Protocol Overview
Open Shortest Path First (OSPF) is a recent entry into the Internet interior routing scene. OSPF Version 2 is documented in RFC 1583 (a lengthy document that I find very difficult to read). Sanctioned by the IETF, it is intended to become Internet's preferred interior routing protocol. OSPF is a link-state routing protocol with a complex set of options and features. Not all of these features are available on all implementations, but some of its advantages are:
- Scalability. OSPF is specifically designed to operate with larger networks. It does not impose a hop-count restriction and permits its domain to be subdivided for easier management.
- Full subnetting support. OSPF can fully support subnetting, including VLSM and non-contiguous subnets.
- Hello packets. OSPF uses small "hello" packets to verify link operation without transferring large tables. In stable networks, large updates occur only once every 30 minutes.
- TOS routing. OSPF can route packets by different criterion based on their Type Of Service (TOS) field. For example, file transfers could be routed over a satellite link while terminal I/O could avoid such high delays. This requires cooperative applications on the end systems.
- Tagged routes. Routes can be tagged with arbitrary values, easing interoperation with EGPs, which can tag OSPF routes with AS numbers.
OSPF has some disadvantages as well. Chief among them are its complexity and its demands on memory and computation. Although link-state protocols are not difficult to understand, OSPF muddles the picture with plenty of options and features.
OSPF divides its routing domain into areas. Area 0, the backbone, is required. This divides interior routing into two levels. If traffic must travel between two areas, the packets are first routed to the backbone. This may cause non-optimal routes, since interarea routing is not done until the packet reaches the backbone. Once there, it is routed to the destination area, which is then responsible for final delivery. This layering permits addresses to be consolidated by area, reducing the size of the link state databases. Small networks can operate with a single OSPF area, which must be area 0.
OSPF divides networks into several classes, including point-to-point, multiaccess, and non-broadcast multiaccess. A serial link connecting two routers together would be a point-to-point link, while an Ethernet or Token Ring segment would be a multiaccess link. A Frame Relay or X.25 cloud would be classified as non-broadcast multiaccess.
Multiaccess networks (like Ethernet) use a designated router (DR) to avoid the problem of each router forming a link with every other router on a Ethernet, resulting in a N^2 explosion in the number of links. Instead, the DR manages all the link state advertisements for the Ethernet. Selecting the DR requires an election process, during which a Backup Designated Router (BDR) is also selected. OSPF provides a priority feature to help the network engineer influence the choice of DR and BDR, but in practice this is difficult. Link layer multicasting is also used, if available, to avoid broadcasts and better target routing updates.
Non-broadcast multiaccess networks (like X.25) also use the designated router concept, but since broadcasts (and presumably multicasts) are not supported, the identity of neighboring routers must be specified manually. A DR on such a network without a complete list of neighbors will cause a loss of connectivity, even though the network is otherwise functional. If possible, I recommend configuring such networks as a collection of point-to-point links, simply to avoid the intricacies of DR election.
OSPF's primary means of verifying continuing operation of the network is via its Hello Protocol. Every OSPF speaker sends small hello packets out each of its interfaces every ten seconds. It is through receipt of these packets that OSPF neighbors initially learn of each other's existance. Hello packets are not forwarded or recorded in the OSPF database, but if none are recieved from a particular neighbor for forty seconds, that neighbor is marked down. LSAs are then generated marking links through a down router as down. The hello timer values can be configured, though they must be consistant across all routers on a network segment.
Link state advertisements also age. The originating router readvertises an LSA after it has remained unchanged for thirty minutes. If an LSA ages to more than an hour, it is flushed from the databases. These timer values are called architectural constants by the RFC.
OSPFs various timers interact as follows:
- If a link goes down for twenty seconds, then comes back up, OSPF doesn't notice.
- If a link flaps constantly, but at least one of every four Hello packets make it across, OSPF doesn't notice.
- If a link goes down for anywhere from a minute to half an hour, OSPF floods an LSA when it goes down, and another LSA when it comes back up.
- If a link stays down for more than half an hour, LSAs originated by remote routers (that have become unreachable) begin to age out. When the link comes back up, all these LSAs will be reflooded.
- If a link is down for more than an hour, any LSAs originated by remote routers will have aged out and been flushed. When the link comes back up, it will be as if it were brand new.
- Ahmad Sofyan : 07.0511.0006
- Nur Arif Mustofa : 07.0511.0079
- Atkha Solikin : 07.0511.0150
- Agus Budi Prasetyo : 07.0511.0005
- Achmad Rudiyanto : 07.0511.0139
0 komentar:
Posting Komentar