Apa yang terjadi ketika sakelar konsumen menerima bingkai Ethernet yang ditandai VLAN?

Misalkan Anda menghubungkan port trunk dari switch jaringan berkemampuan VLAN ke switch jaringan tingkat konsumen (VLAN yang tidak mampu) melalui kabel langsung. Sekarang switch yang pertama mengirim frame Ethernet 802.1Q yang kemudian ditandai. Apa yang harus dilakukan sakelar nanti? Jatuhkan bingkai? Maju bingkai? Perilaku tidak terdefinisi?

Jika perilaku tidak terdefinisi, apa yang paling mungkin?

Sunting: Terima kasih atas jawaban Anda. Untuk meringkas, perilaku konsumen beralih pada:

Cara menangani frame dengan 0x8100di bidang EtherType ¹
Bagaimana menangani frame jumbo, atau frame dengan payload lebih besar dari 1500 byte

Wikipedia memiliki diagram yang bagus membandingkan frame Ethernet yang tidak ditandai dan yang ditandai:

Ada laporan bahwa beberapa sakelar tingkat konsumen melewati bingkai yang ditandai VLAN dengan baik.

_{¹ atau lebih tepatnya, di mana bidang EtherType diharapkan untuk frame yang tidak ditandai}

— netvope
sumber

Saya harap Anda tidak bertanya dengan harapan menggunakan sakelar konsumen di rak produksi di suatu tempat ...

— Mike Pennington

Jawaban:

Saya benar-benar melihat ini di switch murahan. Seseorang telah menghubungkan saklar antara port trunk yang memiliki pasangan vlan. Bingkai diteruskan dengan penandaan vlan utuh. Port lain pada sakelar itu di mana dapat menggunakan vlan yang tidak ditandai.

Switch hanya membutuhkan sumber / tujuan mac untuk memutuskan port mana yang akan meneruskan frame, jadi ini tidak terlalu mengejutkan, frame yang ditandai masih memiliki sumber dan tujuan mac, di lokasi yang sama di header frame.

Perlu diingat bahwa Ethernet sebenarnya mendukung banyak jenis bingkai pada kabel yang sama. Itu dirancang agar cukup fleksibel tentang apa yang bisa dilakukannya.

— Sakit kepala
sumber

Jika sakelar tidak mengetahui Tipe Eter yang digunakan untuk bingkai yang ditandai, ia akan memprosesnya seolah-olah itu adalah Tipe Eter normal. Itu sebagian besar akan bekerja, tetapi bisa gagal dalam pengaturan yang rumit di mana port tujuan tergantung pada MAC dan tag. Misalnya jika Anda memasang bridging firewall antara dua VLAN yang ditandai, sakelar tanpa dukungan VLAN dapat mengirim beberapa paket ke arah yang salah. Selain itu masalah jelas yang dapat terjadi adalah paket-paket dijatuhkan karena mereka melebihi ukuran maksimum bingkai yang tidak ditandai.

— kasperd

Biasanya frame ethernet yang terlalu besar dapat dan dibuang. Di hadapan hal-hal seperti frame berukuran jumbo, frame ethernet besar sulit untuk didefinisikan, sehingga sangat tergantung - tetapi membuang mungkin merupakan perilaku yang paling sering ditemui.

sunting: Untuk menguraikan: Standar IEEE 802.3 Ukuran frame Ethernet adalah 1518 byte, 802,3Q menambahkan 4 byte ke frame sehingga memiliki MTU total 1522 byte yang mungkin terlalu besar untuk beberapa switch.

— pfo
sumber

Bisakah Anda menguraikan apa yang harus dilakukan frame ethernet besar dengan penandaan VLAN 802.1Q?

— Martijn Heemels

Apakah Anda mengatakan tag akan membuat bingkai terlalu besar?

— Shane Madden

@ShaneMadden Beberapa implementasi 802.1q menabrak MTU efektif hingga 1522b untuk frame yang ditandai, yang akan dijatuhkan oleh switch dengan hanya 1500b MTU.

— sysadmin1138

+1 untuk sysadmin1138 dan +1 untuk pfo: Beberapa switch lama akan membuang frame yang ditandai karena 802.1q meningkatkan MTU Ethernet.

— Evan Anderson

Penandaan VLAN meningkatkan ukuran bingkai maksimum sebesar 4 byte sehingga lebih besar dari 1518 byte dan secara definisi merupakan bingkai "jumbo".

— pfo

Switch kelas konsumen akan berusaha untuk meneruskan alamat MAC frame -destinasi yang peduli. Jika alamat MAC tujuan tidak ada dalam tabel CAM-nya, ia akan membanjiri frame dari semua port-nya, kecuali paket yang diterima.

Switch yang menggunakan metode Cut Through forwarding pasti akan meneruskan frame, karena ia mulai meneruskan begitu alamat MAC tujuan dibaca-bahkan jika ukuran total frame lebih besar daripada MTU-karena itu tidak dapat menghitung ukuran bingkai dengan metode penerusan ini.

Suatu saklar yang didasarkan pada teknik Store and Forward mungkin akan (selama ukuran frame <= MTU) melakukan hal yang sama, selama FCS OKE.

Jika switch 802.1Q-incapable menghubungkan perangkat akhir, perangkat akan menerima frame dan membuangnya, karena mereka tidak "tahu" bagaimana memproses frame 802.1Q (type 0x8100).

Saya berspekulasi jika switch kelas konsumen menghubungkan switch yang mampu 802.1Q ( horor! ), Frame akan diteruskan dan diproses oleh 802.1Q-lama, tentu saja, seperti yang diterima pada port trunk.

— dkaragasidis
sumber

Eh. Perangkat titik akhir Linux menangani bingkai yang ditandai dengan baik. Saya telah melihat mereka melakukannya.

— Zan Lynx

@ZanLynx Benar. Meskipun perangkat titik akhir tidak seharusnya menangani frame yang ditandai - Anda melewatkan seluruh titik VLAN dengan mengkonfigurasi perangkat titik akhir untuk menerima dan menangani frame 802.1q.

— dkaragasidis

FCS = perpindahan sirkuit cepat? Apa yang menentukan apakah "FCS baik-baik saja"?

— netvope

@netvope: FCS - Urutan pemeriksaan bingkai: en.wikipedia.org/wiki/Frame_check_afterence

— Evan Anderson

@dkaragasidis Ada beberapa alasan yang sah untuk mengkonfigurasi beberapa host untuk menggunakan bingkai yang ditandai. Tapi yang lebih baik memastikan bahwa penandaan VLAN dinonaktifkan pada port yang menghadap host Anda tidak ingin menggunakan frame yang ditandai. Alasan untuk menggunakan bingkai yang ditandai pada host Linux termasuk satu yang bertindak sebagai router antara VLAN atau server yang harus dapat dijangkau dari klien pada VLAN yang berbeda.

— kasperd