Semakin hari semakin banyak ISP Indonesia yang dipercaya Akamai untuk meng-cache konten-konten akamai , permasalahan timbul karena ISP seperti Idola/Lintas Arta, Telkom, Indosat dll mengadvertise blok IP Akamai Server mereka ke OpenIXP/IIX sehingga daftar nice.rsc juga akan menyertakan blok IP Akamai sebagai prefix lokal Indonesia padahal traffic Akamai yang di host di ISP Indonesia tsb tidak selalu dapat di download dari OpenIXP/IIX biasanya hanya outgoing routingnya saja via OpenIXP/IIX tetapi incoming routingnya tetap melalui pipa International kecuali para pelanggan Speedy atau Firstmedia "mungkin" mereka dapat mendownload konten Akamai secara khusus dari jaringan Speedy / Firstmedia .
berikut bukti akamai Idola/LintasArta di download melalui interface international sedangkan outgoingnya melalui interface lokal dan prefix 202.152.0.0/19 terdaftar di address-list = nice
Permasalahan ini sudah pernah saya tulis juga dalam artikel blog saya terdahulu: http://inetshoot.blogspot.com/2008/11/pemisahan-traffic-ke-ip-akamai-indosat.html , dimana kerancuan prefix Akamai di nice.rsc akan mengakibatkan limitasi bandwidth lokal dan international bisa tidak sesuai pada para pengguna mikrotik yang memanfaatkan nice.rsc
sehingga akan terjadi traffic international akan dianggap iix sehingga bandwidth International akan selalu mentok terpakai karena biasanya limitasi untuk iix akan lebih longgar / lebih besar bandwidthnya padahal umumnya bandwidth International yang di dapat lebih kecil dari pada bandwidth lokal Indonesia.
Untuk itu saya coba menangkap IP Akamai Server yang di advertise oleh ISP Indonesia di OpenIXP/IIX agar para pengguna nice.rsc bisa lebih lanjut mengkondisikan agar traffic Akamai tidak tercampur dengan mangle / queue traffic IIX, atau bisa jadi dikembangkan untuk memanipulasi agar traffic Akamai tsb di redirect ke proxy yang terhubung langsung dengan speedy atau firstmedia hehehe peace....
Langka1:
Buat /ip firewall layer7-protocol
Langka2:
Buat /ip firewall filter forward
Hasilnya akan terdapat pada address-list = "akamai-indonesia"
Seringkali anda harus bepergian ke berbagai tempat dan pada waktu akan mengirim email menggunakan email client seperti outlook kesulitan mengakses smtp, karena sebagian besar smtp dibatasi aksesnya hanya untuk jaringan internal perusahaan atau intranet atau hanya dapat diakses melalui jaringan ISP yang digunakan di kantor
Salah satu solusi praktis bagi anda yang sering bepergian adalah menjadikan smtp.gmail.com untuk outoging smtp di outlook agar tidak perlu melakukan perubahan konfigurasi smtp jika notebook dibawa ke tempat manapun selama ada akses Internet dan smtp.gmail.com port 587 di izinkan oleh firewall hotspot atau router dimana anda terkoneksi dengan Internet.
Petunjuk dari google dapat di lihat pada url berikut untuk outlook 2003
smtp.gmail.com bisa digunakan untuk outgoing mail server (smtp) semua mailbox yang kita miliki dengan klik “More Settings” pada account yang akan kita set , lalu pada tab “Outgoing Server” ceklist “My outgoing server (SMTP) requires authenctication” dan pilih “Log on using” masukkan username gmail yang anda daftarkan di gmail dan masukkan password gmail anda , agar tidak selalu meminta passwrod ceklist “Remember password”
Gambar dibawah adalah tampilan outlook 2007 tetapi harusnya tidak jauh berbeda dengan outlook 2003
Pada tab “Advanced” set “Outgoing server (SMTP) dengan port: 587” dan pilih “Use the following type of encrypted connection = TLS” lalu Klik “OK”
Dengan demikian maka notebook anda bisa mengirim email menggunakan SMTP : smtp.gmail.com dimanapun bisa mengakses Internet.
Jika switch belum di konfigure IP nya pasang kabel konsol + usb to serial , lalu gunakan aplikasi hyperterminal atau putty.exe , jangan lupa nyalakan switchnya juga.
Untuk mengetahui di COM berapa kabel serial tersebut terpasang caranya cek di device-manager , cara paling praktis klik kanan di my computer lalu pilih manage
di contoh ini usb to serial di com13
setelah mengetahui di com berapa jalankan program putty.exe
pilih serial dan ketik com13 lalu klik Open
enter -> enter maka putty akan mendetek kecepatan baud-ratenya kalau sudah bisa komunikasi makan akan muncul CLI dari switch procurve tersebut
ketik : sh run maka akan muncul konfigurasi switch tersebut, di contoh ini switch belum di beri IP statik , untuk itu setup ip statik di vlan1 caranya ketik:
config t vlan1 ip address 192.168.0.1 255.255.255.0
untuk menyimpan konfigurasi ketik:
write mem
Langkah 3
kemudian set ip 192.168.0.2 mask 255.255.255.0 di interface ethernet pada notebook seperti berikut ini:
setelah notebook diset ip 192.168.0.2 netmask 255.255.255.0 maka harusnya dari notebook sudah bisa ping ke 192.168.0.1
Langkah 4
lalu aktfikan tftp solarwind , arahkan direktori ke path dimana file firmware / os switch berada dengan cara klik file->configure->storage klik browse arahkan ke direktori dimana file firmware / os berada kalau sudah klik OK
jangan lupa klik "Start" agar tftp server dijalankan
Langkah 5
di konsole putty ketik: menu maka akan muncul menu dan pilih "Download OS"
masukkan ip tftp server dalam contoh ini: 192.168.0.2 dan nama file dalam contoh ini: H_10_83.swi , kemudian pilih execute
jika semua benar maka proses download os akan dilaksanakan
Jika sudah selesai maka akan ada pesan sbb:
selanjutnya switch harus di reboot, jika tidak boot otomatis ketik: boot, maka switch akan melakukan proses reboot
dan jika sudah berhasil maka kalau di : sh run , maka tampilannya aka sbb:
di sini bisa dilihat bahwa firmware/os switch sudah menggunakan versi baru yang tadi di download
psudo only allows one active mac address to be behind the client.
so if you have a CPE with a customers router or single PC behind it, it works great. If the customer plugs in a switch and tries to hook up two computers that try to get online, it won't work as expected for them, and only one device at a time can receive packets.
Additionally it has less overhead than WDS, and reconnects to the AP faster in the event of a disconnect (WDS has to connect once regular, probe the AP to determine if WDS is supported, then reconnect as a WDS connection), Plus the option of turning off default forwarding on the AP works (To accomplish the same when using WDS you have to get creative and use a bunch of bridge rules).
For a backhaul, you should really avoid using WDS (or psudobridge), you should be using regular station and bridge mode, with no other devices connected, and then routing the data across a /30 subnet, preferably using OSPF (and a redundant path available), but static routing can be used if necessary.
Kalau pake pseudo bridge hanya satu mac-address yang bisa aktif dibelakang access-point-client (APC) , alias di sisi router distribusi yang arp-tablenya hanya bisa kenal satu mac-address router sisi clientnya (semoga ngerti yang saya maksud)
jadi kalau Client Permissive Equipment (CPE) hanya dihubungkan ke satu router client menggunakan pseudobridge akan sangat bagus, tapi kalau CPE dihubungkan ke switch lalu ada lebih dari satu komputer maka hanya salah satu komputer saja yang arp nya masuk di arp-table router ISP , jadi kalau clientnya gak punya router dari CPE langsung ke switch lalu masuk beberapa komputer sisi APC harus dijadiin station-wds
Tapi dijelaskan oleh Brian, bahwa pseudobridge overheadnya lebih kecil dari WDS, alias lebih efisien dibanding WDS , dan pseodobridge kalau disconnect , connect lagi ke AP nya lebih cepat dibanding WDS.
Untuk backhaul kata Brian, sebaiknya menghindari pakai WDS tapi pakai mode station dan bridge biasa lalu lakukan routing per /30 subnet bisa pakai ospf atau static routing.
Semoga penjelasan ini bermanfaat
Salam Harijanto P. http://htsolusi.net http://pt-pda.net
Baru-baru ini saya mencoba produk ubiquiti rocket yang digunakan sebagai bridging antar BTS, maklum masih newbie dengan produk ini jadi belum paham benar karakternya.
Kasus yang saya hadapi:
Untuk menghubungkan satu router mikrotik ke router mikrotik lainnya melalui ubiquiti rocket saya harus membuat eoip-tunnel agar ospf antar router berfungsi dengan baik, entah mengapa harus menggunakan eoip-tunnel kalau menggunakan dynamic routing ospf karena kalau ping ptp dan static routing bisa berfungsi
Sepertinya antar ubiquiti rocket harus menggunakan access-point wds dengan station wds kalau ingin menjalankan transparent bridge, kalau dari hasil pengamatan antara ubiquiti rocket yang menggunakan wds dan tidak di tabel arp yang ada di router mikrotik jelas kalau ubiquiti rocket yang menggunakan wds arp tablenya antara ap-wds, station-wds dan router mikrotik mac-addressnya masing-masing terpisah sedangkan kalau ubiquiti rocket yang non wds arp tablenya antara ap, station dan router mikrotik mac-address station dan router sama-sama menggunakan mac-address ubiquiti jadi seperti mac clonning pada radio senao , arp tablenya bisa dilihat pada gambar berikut:
berikut adalah screen capture ubiquiti rocket dengan ap-wds:
berikut adalah screen capture ubiquiti rocket dengan station-wds:
berikut adalah screen capture ubiquiti dengan ap non wds:
berikut adalah screen capture ubiquiti dengan station non wds:
Hari ini saya kedatangan kawan lama , seperti biasa dia minta bantuan ngoprek Mikrotik masalahnhya dia ingin memasang server penyaring spam virus dll dalam mode bridge tetapi kalau suatu saat server penyaring tsb bermasalah maka traffic harus di bypass melalui port lainnya
kurang lebih topologinya spt ini:
Jadi semisal link ether2 putus maka data akan mengalir melalui ether1 , sedangkan jika link ether1 putus data akan mengalir melalui ether2, jika kedua link tidak putus maka data akan mengalir melalui ether1 menggunakan mekanisme RSTP: http://wiki.mikrotik.com/wiki/Manual:Interface/Bridge
dalam percobaan ini saya menggunakan RB750G yang terdiri dari RSTP-A dan RSTP-B, dimana RSTP-A pada ether3 terhubung langsung dengan router / koneksi Internet sedangkan RSTP-B terhubung dengan notebook
Berikut adalah foto RSTP-A
Berikut adalah foto RSTP-B
Pada RSTP-A Konfigurasi bisa dilihat sbb:
Pada RSTP-B konfigurasi bisa dilihat sbb:
Yang membedakannya hanya pada :
[admin@RSTP-B] /interface bridge port> /interface bridge port set path-cost=20 interface=ether2
jadi di RSTP-A dan RSTP-B untuk interface=ether2 path-cost dibuat 20 sedangkan ether1 path-cost = 10
sehingga pada keadaan normal data akan dialirkan melalui ether1 ke ether3 melalui bridge
untuk uji coba saya lakukan ping ke dns google 8.8.8.8 dari notebook lalu salah satu kabel misal ether1 saya cabut maka data akan mengalir lewat ether2
dan ketika kabel ether1 di pasang lagi maka data akan kembali melalui ether1
atau sebaliknya
jadi kesimpulannya dua RB750G tersebut bisa menjadi bridge RSTP yang menjadi solusi fail-over layer2 yang ekonomis dan praktis
Wah sudah lama gak nulis di blog , kebetulan malam ini iseng pengen tahu karakter game Point Blank http://pb.gemscool.com/
Setelah mendownload aplikasi dan patch dan mendaftar user di gemscool lalu selanjutnya saya coba mainkan mh.... ya seperti Counter Strike permainannya tapi karena tangan sudah lama gak dibuat untuk main game jadi ya kaku kaku gitu harus menghafalkan tombol2 navigasi lagi yang kurang lebih seperti CS.
yang menarik pada waktu iseng saya klik tombol Check sebelum mengklik Start yang dilakukan oleh PB adalah melakukan download patch dan ternyata bandwidth 10Mbps di sikat habis wak.... waduh ini game kalau lagi ngepatch sadis punya ternyata mh... iseng saya torch di mikrotik ternyata patchnya via port 80 alias http wah ini bisa di bantu squid nih.
Benar saja setelah saya redirect port 80 ke squid hasilnya sesuai dengan yang saya inginkan yaitu file2 patch bisa di cache di squid proxy sehingga trafficnya sekarang yang besar yang kearah squid proxy
Gambar berikut adalah bukti bahwa proses patch bisa di bantu squid dengan hasil tail -f /var/log/squid/access.log banyak sekali TCP_HIT maupun TCP_MEM_HIT untuk file2 .zip artinya sekarang patch PB diambil dari cache yang ada di squid
Berikut adalah tampilan torch mikrotik pada interface wlan1 untuk ip source 10.5.50.232 ternyata pada waktu patch Tx Rate sangat tinggi sekali mencapai 8.2Mbps , untungnya saat ini sudah di dst-nat ke squid sehingga Data Rate yang menuju ke Jakarta tidak sampai 8.2Mbps karena sebagian besar file patching telah ada di squid proxy
Ini adalah buktinya pada waktu PB melakukan patching dan port 80 diredirect ke squid proxy di mikrotik backbone Jakarta-Cirebon tidak terjadi lonjakan traffic sd 8Mbps lebih seperti yang terjadi pada mikrotik distribusi hotspot di kantor.
Jadi kesimpulannya traffic patch Point Blank sangat bisa di bantu oleh mekanisme cache squid proxy, sedangkan pada saat permainan berlangsung dengan skenario notebook saya sebagai client yang joint ke server public PB , data rate yang terjadi sangat kecil sekitar 15Kbps-16Kbps
Jadi kesimpulannya:
1. Proses Patch game Point Blank yang sangat berat bisa di bantu dengan mekanisme cache dari squid 2. Pada saat permainan berlangsung alokasi bandwidth per PC game bisa diset dari 32Kbps - 128Kbps 3. Buat alokasi bandwidth khusus yang berasal dari PC Game menuju ke squid proxy
adapun di /etc/squid/squid.conf saya coba set parameter berikut:
Hari ini dapet mainan dari seorang teman sebuah Komputer Max-Term / Maxspeed dengan spesifikasi sbb:
Penasaran mau tahu bisa menangani paket sebanyak apa saya lakukan percobaan dengan menggunakan btest.exe dari notebook dengan spesifikasi sbb:
Percobaan 1: Max-Term dijalankan BTest-Server lalu dari notebook lenovo menjalankan btest.exe sebanyak 15 windows dengan kombinasi udp dan tcp packet, hasilnya:
Tx Packet mencapai 8.658 pps dan Rx Packet 14.304 pps pada Tx 76.5 Mbps dan Rx 91.1 Mbps dengna latency mencapai 50 ms - 80 ms cpu 100%
Percobaan 2: Notebook menjalankan btest.exe sebagai server dan Max-Term melakukan bandwidth-test ke notebook sebanyak 25 terminal dengan protocol udp hasilnya:
Tx Packet mencapai 3.280 pps dan Rx Packet 8.061 pps pada Tx 38.7Mbps dan Rx 97.1Mbps dengna latency mencapai 3 ms cpu 18%
Kesimpulan: Harusnya dengan MaxTerm / Maxspeed + Mikrotik 4.4 Level 4 bisa mem-forward packet 0 - 10000 pps pada throughput 0 - 20 Mbps dengan lancar
Halo apakabar? Selamat Tahun Baru 2010 sudah lama saya tidak menulis blog saya ini, kebetulan lagi liburan Tahun Baru saya coba tulis contoh kasus BGP Failover antar BTS.
Dalam contoh kasus BGP Failover antar BTS skenarionya adalah sbb:
Dengan skenario diatas maka BTS Slipi dan BTS Meruya menjadi full-protection (bahasa kerennya XL / Moratel / Icon+ untuk backbone fiber-optic mereka di pulau Jawa)
Dengan demikian ada 4 BGP Router yang terlibat dalam skenario ini, yaitu: Router International dan Router OIXP/IIX yang keduanya ada di Gedung Cyber dan Router Mikrotik di BTS Slipi dan BTS Meruya
Adapun link yang antara Gedung Cyber ke Slipi menggunakan Fiber Optic sedangkan antara Gedung Cyber ke Meruya menggunakan Microwave 15Ghz (Pake ISR tentunya) dan Dari Meruya ke Slipi menggunakan WiFi IEEE 802.11 tentunya pake Mikrotik RB600
Ok langsung saja berikut adalah screen capturenya semoga bermanfaat bagi yang membacanya, oh ya dalam screen capture ip-ip publik yang relevan tidak saya sensor agar bisa menjadi contoh nyata karena semangat saya nulis adalah untuk berbagi jadi mohon agar tidak di serang ya "semoga".
Konfigurasi di Router IIX di Cyber pada Cisco 7206VXR G2:
neighbor ke Mikrotik Meruya
neighbor ke Mikrotik Slipi
route-map IIXNICEONLY-EXPORT
as-path 2 , tujuannya untuk memfilter hanya prefix dari AS7597 (IIX) dan AS7717 (NICE/OIXP) yang akan di advertise ke BGP Meruya dan Slipi, untuk di implementasikan ke route-map IIXNICEONLY-EXPORT diatas
access-list 100, tujuannya selain prefix dari AS7597 (IIX) dan AS7717 (NICE/OIXP) juga prefix asli milik Datautama di advertise ke BGP Meruya dan Slipi, untuk di implementasikan ke route-map IIXNICEONLY-EXPORT diatas
Dengan demikian maka BGP Meruya dan Slipi akan menerima prefix/routing table IIX+OIXP+Datautama
Jika konfigurasi ke 4 BGP tersebut telah berfungsi maka hasil "sh ip bgp sum" di router IIX/OIXP di cyber adalah sbb:
Konfigurasi di Router Internatinoal di Cyber: neighbor ke Mikrotik Meruya
neighbor ke Mikrotik Slipi
route-map KOSONG
tujuan dari as-path access-list 11 deny .* pada route-map KOSONG adalah untuk memfilter semua prefix dari International agar tidak di advertise ke BTS Meruya dan Slipi, karena Mikrotik Meruya dan Slipi hanya perlu prefix IIX/OIXP agar routing menuju ke IIX/OIXP langsung belok ke Router IIX/OIXP di Cyber sedangkan default-route menuju ke Router International.
Sebagai catatan: hal terpenting dalam bermain BGP maupun OSPF adalah pemahaman tentang filtering as-path , access-list, prepend, subnet dan supernet.
Jika konfigurasi ke 4 BGP tersebut telah berfungsi maka hasil "sh ip bgp sum" di router International di cyber adalah sbb:
Konfigurasi di Router Mikrotik Meruya:
ip-address, interface backhaul adalah interface yang menghadap ke Cyber menggunakan Microwave 15Ghz
bgp-instance
bgp-peers Meruya ke International Cyber, hold time di buat 20 agar BGP lebih responsif terhadap kondisi link antar BGP up atau down
bgp-peers Meruya ke IIX Cyber, hold time di buat 20 agar BGP lebih responsif terhadap kondisi link antar BGP up atau down
bgp-peers Meruya ke Slipi, hold time di buat 20 agar BGP lebih responsif terhadap kondisi link antar BGP up atau down
Berikut adalah konfigurasi routing-filter yang merupakan bagian terpenting dan paling rumit untuk dipahami, pada bagian BGP Prepend tujuannya agar ke arah PENINSULA-EXPORT di prepend 2 kali agar ke arah AS24521-EXPORT lebih pendek sehingga menjadi prioritas, kecuali jika link Meruya ke Cyber putus baru akan menggunakan link Meruya-Slipi-Cyber.
Konfigurasi di Router Mikrotik Slipi:
ip-address, interface ether1 adalah interface yang menghadap ke Cyber menggunakan Fiber Optic
bgp-instance
bgp-peers Slipi ke International Cyber, hold time di buat 20 agar BGP lebih responsif terhadap kondisi link antar BGP up atau down
bgp-peers Slipi ke IIX Cyber, hold time di buat 20 agar BGP lebih responsif terhadap kondisi link antar BGP up atau down
bgp-peers Slipi ke Meruya, hold time di buat 20 agar BGP lebih responsif terhadap kondisi link antar BGP up atau down
Berikut adalah konfigurasi routing-filter yang merupakan bagian terpenting dan paling rumit untuk dipahami, pada bagian BGP Prepend tujuannya agar ke arah PRESISI-EXPORT di prepend 2 kali agar ke arah INTL-CYBER-EXPORT lebih pendek sehingga menjadi prioritas, kecuali jika link Slipi ke Cyber putus baru akan menggunakan link Slipi-Meruya-Cyber.
Dengan demikian maka pada kondisi Fiber Optic Slipi-Cyber normal default-route pada Mikrotik di Slipi adalah sbb:
DAb Destination 0.0.0.0/0 gateway 203.89.26.49 adalah entry bgp yang di terima, sedangkan Db Destination 0.0.0.0/0 gateway 203.89.24.185 dengan warna biru adalah entry bgp yang tidak diterima atau dengan kata lain standby kalau sampai gateway 203.89.26.49 putus maka gateway 203.89.24.185 akan digunakan melalui interface ipip-P6toP2 yang merupakan ipip-tunnel dari Mikrotik Slipi ke Mikrotik Meruya melalui link WiFi IEEE 802.11 menggunakan RB600
Sedangkan untuk kondisi Microwave 15Ghz Meruya-Cyber normal default-route pada Mikrotik Meruya adalah sbb:
DAb Destination 0.0.0.0/0 gateway 203.89.26.1 adalah entry bgp yang di terima, sedangkan Db Destination 0.0.0.0/0 gateway 203.89.24.186 dengan warna biru adalah entry bgp yang tidak diterima atau dengan kata lain standby kalau sampai gateway 203.89.26.1 putus maka gateway 203.89.24.186 akan digunakan melalui interface ipip-P2toP6 yang merupakan ipip-tunnel dari Mikrotik Meruya ke Mikrotik Slipi melalui link WiFi IEEE 802.11 menggunakan RB600
Demikian kiranya sedikit sharing ilmu semoga bermanfaat bagi semua yang membacanya
