PADDING ETHERNET, SEKILAS PANDANG
Mengapa pesan pendek dapat muncul sebagai frame yang lebih panjang?
Ethernet dapat menambahkan padding sebelum FCS untuk memenuhi format frame MAC minimumnya. Padding berada di luar paket IPv4 dan tidak boleh menjadi data aplikasi. Perangkat lunak penangkapan dapat mengamati pemrosesan sebelum padding atau menerima rekaman tanpa FCS, sehingga panjang yang ditampilkan saja tidak membuktikan adanya transmisi yang kurang ukuran. Verifikasi titik pengamatan dan konvensi panjang.
Bangun frame luar
Padding memenuhi format luar; padding tidak menambahkan makna aplikasi.
Tentukan lokasi pengamat
Perangkat lunak dapat melihat tahap yang berbeda dari tautan fisik.
Hormati batas dalam
Untuk IPv4, gunakan total panjang IP alih-alih memperlakukan padding sebagai data.
Verifikasi hitungan
Nyatakan header, tag, dan byte FCS mana yang termasuk dalam panjang tersebut.
Verifikasi penangkapan
Catat arah, offload, panjang yang dipertahankan, dan pengaturan FCS.
Verifikasi parser
Pastikan bahwa panjang lapisan atas menentukan konten aplikasi yang valid.
Daftar periksa pemilihan dan verifikasi — perluas
| Periksa | Apa yang harus dikonfirmasi | Cara memverifikasi |
|---|---|---|
| Konvensi frame | Header, tag, dan FCS | Dokumentasikan awal dan akhir hitungan secara tepat. |
| Titik pengamatan | Sebelum NIC, kabel, atau penerima | Pertahankan pengaturan antarmuka dan pengumpulan. |
| Kelengkapan penangkapan | Panjang asli versus panjang yang dipertahankan | Periksa pemotongan dan batas pengumpulan. |
| Batas protokol | Panjang IP yang valid atau panjang protokol lainnya | Periksa panjang yang ditentukan dan perilaku parser. |
| Bukti kesalahan | Penghitung, arah, dan waktu | Korelasikan lalu lintas yang diketahui di kedua ujung. |
Contoh konseptual, tidak berskala, bukan pengukuran atau klaim implementasi produk tertentu.
Sebuah PLC mengirim pesan status pendek, namun konten yang ditransmisikan melalui Ethernet lebih panjang. Sebuah penangkapan menunjukkan 60 byte, sementara dokumentasi menjelaskan frame minimum 64 byte. Jangan langsung menyimpulkan bahwa switch menghapus empat byte. Pesan aplikasi, enkapsulasi Ethernet, dan penangkapan perangkat lunak adalah lapisan pengamatan yang berbeda. Menempatkan padding di posisi yang benar menjelaskan kontradiksi yang tampak.
Pisahkan pesan, paket IP, dan frame Ethernet
Aplikasi peduli tentang status, perintah, atau pengukuran, tetapi transmisi memerlukan informasi yang dapat dikenali oleh peralatan jaringan. Bayangkan pesan sebagai catatan, paket IP sebagai amplopnya, dan frame Ethernet sebagai kemasan luar untuk tautan ini. Analogi ini menjelaskan lapisan, bukan tiga kotak fisik: kabel membawa urutan bit yang berkesinambungan.
Dalam contoh Ethernet tanpa tag biasa yang digunakan di sini, frame MAC berjalan dari alamat tujuan hingga urutan pemeriksa frame, atau FCS. Alamat MAC mengidentifikasi pengirim atau penerima pada tautan; FCS membantu penerima memeriksa kesalahan transmisi. Preamble mendahului frame, dan celah antarframe adalah waktu diam di antara transmisi. Keduanya bukan bagian dari hitungan 64 byte ini.
Minimum berlaku untuk frame MAC luar, bukan untuk panjang setiap instruksi PLC. Saat membaca dokumentasi atau penangkapan, pertama-tama tentukan di mana penghitungan dimulai dan berakhir. Mencampur data aplikasi, header, dan FCS dapat membuat enkapsulasi biasa tampak seperti konten aplikasi tambahan.
Tambahkan padding sebelum membentuk urutan pemeriksa frame
Jika konten lapisan atas yang disediakan terlalu pendek, pemrosesan transmisi Ethernet menambahkan padding setelah konten tersebut dan sebelum FCS. Ini seperti pengemasan pelindung: memakan ruang tanpa menambahkan kata pada catatan. Apakah perangkat lunak, driver, atau perangkat keras melakukan operasi tertentu bergantung pada antarmuka jaringan atau implementasi tertanam.
Pertimbangkan contoh yang sengaja dibatasi: header Ethernet tanpa tag sebesar 14 byte membawa paket IPv4 sebesar 28 byte. Paket IP tersebut dapat terdiri dari header IPv4 biasa dan header UDP, tanpa payload aplikasi UDP. Menambahkan 18 byte padding dan FCS empat byte menghasilkan frame MAC sebesar 64 byte. Ini mengilustrasikan strukturnya; ini bukan pengukuran perangkat FCTEL.
Padding termasuk dalam konten yang dilindungi oleh checksum Ethernet. Padding tidak dapat diubah secara sembarangan setelah FCS terbentuk. Penerima memeriksa frame yang diterima, bukan hanya pesan aplikasi. Tidak diperlukan perhitungan CRC untuk memahami urutannya: bentuk konten frame yang diperlukan, lalu hasilkan nilai pemeriksa yang sesuai.
Padding tidak boleh menjadi data aplikasi tambahan
Untuk IPv4, field total-length pada header IP mendefinisikan panjang paket IP, termasuk header dan datanya tetapi tidak termasuk padding Ethernet luar. Penerima meneruskan bagian IP ke atas untuk interpretasi lebih lanjut. RFC 894 secara eksplisit memisahkan padding dari paket IP dan menetapkan padding nol byte bila diperlukan untuk enkapsulasi yang dijelaskannya.
Parser lapisan atas tidak boleh memperlakukan semua byte Ethernet yang tertangkap sebagai konten aplikasi. Parser harus memvalidasi panjang dan batas protokolnya alih-alih menambahkan packing luar ke sebuah perintah. Parser juga tidak boleh begitu saja menghapus setiap nol di akhir: nol bisa merupakan data yang valid. Protokol, bukan tampilan visual suatu byte, yang menentukan batasnya.
Protokol lapisan dua lainnya memerlukan aturan enkapsulasi tersendiri; total length IPv4 tidak dapat diterapkan secara mekanis ke setiap protokol. Padding tidak boleh membawa instruksi kontrol privat atau memori yang tidak diinisialisasi. Kebiasaan praktisnya adalah memverifikasi batas frame luar dan batas pesan dalam secara terpisah.
Mengapa perangkat lunak dapat menampilkan 60 byte atau bahkan lebih sedikit
Perangkat lunak penangkap tidak selalu menerima representasi lengkap di kabel. Banyak antarmuka memeriksa FCS yang masuk tanpa menyerahkan empat byte tersebut ke sistem operasi. Oleh karena itu, perangkat lunak dapat mencatat 60 byte yang sesuai dengan frame MAC 64 byte yang lengkap di kabel. Dokumentasi Wireshark menyoroti perbedaan ini: panjang yang ditampilkan hanya 60 tidak membuktikan adanya transmisi berukuran kurang.
Tangkapan di sisi pengirim dapat mengamati titik lain, sebelum perangkat keras menambahkan padding dan FCS. Rekamannya bisa lebih pendek dari 60 byte meskipun perangkat keras kemudian menghasilkan frame terkirim yang valid. Layar pengirim, layar penerima, dan pengamatan tautan fisik adalah sudut pandang yang berbeda. Membandingkan dua panjang yang ditampilkan saja tidak dapat membuktikan bahwa peralatan di antaranya menghapus konten.
Bedakan juga panjang asli dari panjang yang tertangkap. Kolektor mungkin hanya menyimpan awal setiap frame, sehingga tidak setiap byte asli tentu tersimpan. Periksa pengaturan penangkapan, pengiriman FCS, arah, dan perilaku offload, lalu bandingkan bukti dari rekan. Membuktikan representasi fisik di kabel memerlukan metode pengujian yang sesuai dengan kondisi akuisisi yang dinyatakan.
Pemrosesan VLAN tidak berarti jumlah padding yang tetap
Byte padding 18 hanya berlaku untuk contoh sebelumnya. Panjang konten, penandaan, dan pemrosesan enkapsulasi yang berbeda mengubah jumlah yang diperlukan. Tag VLAN menempati sebagian wilayah header; jangan menghitungnya dua kali bila sudah termasuk. Ukuran frame minimum dan unit transmisi maksimum, atau MTU, juga merupakan konsep yang berbeda.
Switch menerima frame, mengidentifikasi tujuan penerusan, dan membentuk keluaran yang sesuai pada tautan berikutnya. Peralatan yang menambahkan atau menghapus tag harus mempertahankan persyaratan keluarannya. Dokumen pemecahan masalah Cisco yang dirujuk mengilustrasikan kasus platform tertentu di mana penghapusan tag memerlukan padding lagi. Dokumen itu membantu menjelaskan batas pemrosesan, bukan implementasi internal universal untuk setiap switch.
Padding normal pada pesan pendek yang lengkap bukanlah kesalahan. Frame yang benar-benar berukuran kurang, transmisi abnormal akibat tautan rusak, dan rekaman tangkapan yang terpotong saat pengumpulan memerlukan penyelidikan yang berbeda. Nama dan kondisi penghitung port berbeda-beda menurut peralatan. Mengorelasikan penghitung dengan waktu dan arah tangkapan lebih berguna daripada mengganti switch hanya karena sebuah rekaman tampak pendek.
Terapkan pembedaan ini pada koneksi switch industri
Halaman switch Fast Ethernet lima port mini DIN-rail FCTEL yang dipublikasikan mencantumkan lima port listrik Ethernet dan adaptasi 10/100M. Ini memberikan dasar produk nyata untuk skenario koneksi PLC dan HMI. Ini tidak menetapkan fasilitas penangkapan, port mirroring, kontrol padding khusus, atau ambang kesalahan tertentu. Verifikasi konfigurasi yang dipilih terhadap dokumentasinya sendiri.
Jika satu terminal berulang kali mengirim pesan status pendek sementara terminal lain mentransfer file yang lebih besar, jumlah byte aplikasi saja tidak menggambarkan beban port. Setiap frame juga mengonsumsi peluang enkapsulasi dan transmisi, termasuk jarak yang diperlukan. Banyak pesan kecil dapat menggunakan sumber daya pemrosesan dan tautan. Mulailah dengan pengamatan laju frame, lalu lintas aktual, dan siklus aplikasi daripada memerlukan rumus yang rumit.
Jika aplikasi yang diangkut secara transparan tampak memperoleh byte tambahan di akhir, pertama-tama verifikasi batas protokol dan parser. Bandingkan apa yang diamati oleh sumber, konverter mana pun, dan tujuan. Jangan otomatis memperlakukan padding Ethernet sebagai bagian dari pesan serial, atau mengubah mode peralatan hanya untuk menghilangkan padding. Tentukan dulu lapisan yang terdampak.
Gunakan tiga pertanyaan untuk mempersempit penyelidikan lapangan
Pertama, identifikasi titik pengamatan: sebelum transmisi sumber, setelah penerimaan rekan, atau salinan yang disediakan oleh switch. Kedua, dokumentasikan konvensi panjang: header yang disertakan, ketersediaan FCS, dan apakah frame lengkap dipertahankan. Ketiga, korelasikan panjang protokol, payload, dan penghitung kesalahan untuk lalu lintas aplikasi yang sama. Satu tangkapan layar yang menunjukkan 60 byte tidaklah cukup.
Untuk perbandingan, gunakan pesan pendek yang diketahui dalam lingkungan pengujian terisolasi atau jendela pemeliharaan yang disetujui. Pertahankan tangkapan asli dan parameter akuisisi dari kedua ujung. Pastikan aplikasi hanya mengekstrak konten validnya dan komunikasi biasa tetap berlanjut. Pengujian semacam itu memvalidasi konfigurasi dan jalur tersebut; satu tampilan alat tidak mendefinisikan setiap antarmuka dan switch.
Terakhir, amati apakah anomali mengikuti port, kabel, atau metode penangkapan. Simpan bukti mentah, bukan hanya tangkapan layar yang dianotasi. Prinsipnya sederhana: frame luar memiliki format minimum, aplikasi dalam memiliki batas panjangnya sendiri, dan perangkat lunak penangkap mencatat satu tahap pemrosesan. Memisahkan ketiganya membantu menemukan kesalahan yang sebenarnya.
Sumber dan bukti produk
Wireshark: Ethernet; IETF RFC 894, April 1984; Dokumen pemecahan masalah padding Cisco, diperbarui Juli 16, 2021. Mekanisme umum tidak memindahkan perintah khusus platform atau kesimpulan cacat ke peralatan lain. Bukti produk: Switch Fast Ethernet lima port mini DIN-rail FCTEL, halaman berbahasa Mandarin. Verifikasi versi yang dipilih. Ilustrasi adalah konsep generik yang dibuat dengan bantuan AI.
Diterjemahkan dari artikel teknis berbahasa Mandarin: Baca artikel asli berbahasa Mandarin.
Pertanyaan praktis yang umum
Apakah penangkapan 60 byte merupakan frame pendek yang tidak valid?
Belum tentu. Penangkapan umum menghilangkan FCS empat byte. Verifikasi titik pengamatan, panjang asli, dan panjang yang tertangkap.
Apakah padding menjadi perintah PLC baru?
Seharusnya tidak. Parser harus menggunakan panjang protokol lapisan atas alih-alih memperlakukan padding luar sebagai data aplikasi tambahan.
Apakah setiap pesan pendek memerlukan byte padding 18?
Tidak. Delapan belas byte hanya berlaku untuk contoh tanpa tag dalam artikel ini; konten asli dan enkapsulasi menentukan padding sebenarnya.
Cakupan dan bacaan lanjutan
Konsep generik padding Ethernet dan penangkapan, bukan pengukuran atau perilaku spesifik model yang dijamin.
Panduan CRC dan FCS terkait · Panduan preamble dan frame-gap terkait
