tcpdump is a powerful command-line packet analyzer; and libpcap, a portable C/C++ library for network traffic capture.
Dalam tulisan Saya kali ini, Saya akan menceritakan sebuah Production Case yang cukup me-musingkan, sekaligus membuat bingung Saya dan Team yang menangani Case tersebut.
TL;DR
Pada siang hari di saat Saya dan para kolega sedang menikmati coffe break, tiba-tiba kita mendapatkan pesan dari salah satu client yang kita manage service openstack-nya. Dalam pesannya mereka menyampaikan bahwa, terdapat salah satu Tenant yang Floating IP-nya tidak bisa diakses dari manapun.
Pesan tersebut seketika membuat Saya yang tadinya sedang menikmati sebatang Sampoernah Mild, buru-buru untuk membuka laptop.
Quick Check
Segera setelah itu Saya melakukan pengecekan, apakah benar terjadi hal seperti dalam pesan yang client sampaikan.
1. Testing ICMP Connection
Ketika Saya mencoba melakukan testing ICMP koneksi menggunakan ping, dari Host controller menuju VM pada tenant yang bermasalah, hasilnya semua running well.
Di dalam hati Saya berkata "oh, harusnya aman ini, orang di-ping aja bisa... Paling cuman Security Groups..."
2. Testing Access SSH
Dapat terlihat bahwa ketika melakukan akses ssh ke FIP tersebut menggunakan argument debug ( -vvv ), connection established. Namun session SSH tidak terbuka-buka.
Di dalam hati Saya berkata lagi, "Loh,, kok kagak bisa yak!". Kemudian Saya dan Team sedikit berfikir, mungkin karena MTU yang berbeda.
3. Testing Ping Jumbo Frames
Setelah dilakukan percobaan ping ke vRouter pada tenant tersebut dengan Jumbo Frame, hasilnya memang tidak bisa dilakukan. Namun ternyata vRouter pada tenant tersebut memang menggunakan MTU 1500, sehingga hal tersebut wajar terjadi.
Saya berkata lagi, namun kali ini tidak dalam hati "INI KENAPA OYYYY!!!". Teman Saya yang sedang handle pekerjaan yang lebih santai, tertawa melihat Saya yang terlihat puyeng.
Saya mencoba memutar otak; skenario apa yang perlu Saya coba lagi, hingga Saya mendapat ide...
4. Testing SSH Access ( VM -> Controller)
Jika akses SSH dari [Controller -> VM] tidak bisa, "seharusnya" SSH dari [VM -> Controller], juga tidak bisa.
Ternyata hasilnya sebaliknya, SSH dari [VM -> Controller] bisa dilakukan.
Dalam hati Saya berkata "Loh kok aneh.....!"
In-depth Check
1. Service Network Openstack
Saya melakukan pemeriksaan di semua service network openstack. Namun tidak ditemukan adanya error yang menyebabkan hal semacam ini terjadi.
2. Firewall
Pemeriksaan Firewall di semua Host dan VM untuk memastikan bahwa tidak ada firewall yang menghadang paket. Namun tidak ditemukan adanya tanda - tanda firewall penghadang.
3. TCPdump & Wireshark
Di saat-saat despreate seperti ini TCPdump dan Wireshark merupakan perfect combination
TCPDump DARI CONTROLLER
Di sini Saya menggunakan Tmux window 1 dan window 2. Keduanya melakukan eksekusi command yang berbeda.
### Window 1
tcpdump -ni team0.1102 -s 65535 host 172.16.100.228 -w debug-ssh.pcap
### Window 2
ssh -vvv 172.16.100.228Keduanya Saya biarkan berjalan sekitar ±5 menit.
IMPORT KE Whireshark
Dari visualisasi pada Wireshark tersebut sudah dapat terlihat pokok ujung dari permasalahan ini.
Mac-address fa:16:3e:3c:42:16, merupakan mac dari vRouter tenant yang bermasalah. Jika dilihat pattern yang terjadi; semua TCP Retransmission, Dup ACK terus menerus terjadi dan tidak ada paket yang berhasil melewati vRouter tenant tersebut.
Final Action
Setelah melakukan diskusi dengan Team dan Client, kita memutuskan untuk melakukan recreate vRouter pada tenant tersebut, dan melakukan konfigurasi Gateway yang lebih proper.
After Recreate vRouter
Berikut tampilan visualisasi TCPDump setelah dilakukan Action Recreate vRouter.
Dapat dilihat hasil visualisasi TCPDump dari akses SSH yang menggunakan vRouter baru & Gateway yang lebih proper tidak menunjukkan adanya TCP Retransmission ataupun Dup ACK .
Akhirnya setelah semuanya selesai, baru Saya bakar lagi sebatang Sampoerna Mild yang baru saja buka bungkus.
Reference
- D.3. tcpdump: Capturing with “tcpdump” for viewing with Wireshark
https://www.wireshark.org/docs/wsug_html_chunked/AppToolstcpdump.html
- tcpdump(1) man page | TCPDUMP & LIBPCAP
https://www.tcpdump.org/manpages/tcpdump.1.html
- TCP Retransmission Timeout (RTO): Causes & Performance
- TCP Series #3: Network Packet Loss, Retransmissions, and Dup Acks
https://accedian.com/blog/network-packet-loss-retransmissions-and-duplicate-acknowledgements/