Waktu itu, 24-Jun-2003, kamu (adi) menulis: > > bisa kasih contoh tidak? soalnya kalau saya grep dapatnya > cuman arp broadcast ;-) >
wah kebetulan ga ada tcpdump di pc yang skrg dipakai. Mungkin: tcpdump -nni ethx arp > kalau di-tcpdump proto UDP/TCP memang bisa dilihat mac-addr > yang sudah direwrite oleh LVS. tapi yang salah lihat adanya > kebocoran arp. ini baik di LVS maupun di real server sama. > pake direct routing ya? > > berarti tidak sama dengan 'redirect' ala iptables/ipchains ya. > saya jadi kurang mengerti, mengapa itu jadi ada di linux. > Kan tugas redirectnya sudah ditangani sama load balancer, jadi ngapain real server ikut-ikutan redirect. Kecuali kalau memang ada specific purpose. Problem ARP-nya kan menyebabkan request langsung ke real server instead ke load balancer, karena arp yang tercatat satu IP double MAC Address. Jadi redirect dari real server ke mesin lain nggak menjawab masalahnya. > > kalau bisa sih jangan terlalu banyak patch. di atas itu jadi perlu > patching :-) sebenarnya sudah dicoba tanpa patch cem-macem, cuman Kenapa nggak implementasi LVS/NAT? tidak ada IP yang sama. Btw yang Anda implementasikan model apa? Model tunnel kalau nggak salah harus punya alias IP sebanyak real servernya. Dan ini bisa jadi SPOF. > patch untuk LVS-nya saja. saya ingin tahu, kenapa real service > yang sudah dapat weight zero, masih saja ada paket (SYN) yang > masuk, dan stuck. 'service' sendiri jelas tidak jalan, jadi > kalau toh masih dapat giliran, ini kok tidak dapat ECONREFUSED? > bug di implementasi LVS? > Mungkin. Kalau weight-nya zero, kenapa masih dipasang sebagai real server? > > he.. he.. bagaimana, asik kan? ;p > sip tenan :)) -- fade2bl.ac -- Right or wrong my list. Unsubscribe option is currently unavailable. Indeed, it's available upon request .. but: cepek dulu donk!
