Lalu lintas jaringan tampaknya tidak meninggalkan bagasi


8

Saya sedang dalam proses menyusun beberapa server virtualisasi baru, dan bagian dari itu adalah untuk mendapatkan beberapa pipa bandwidth tinggi ke dalamnya. Tujuan utamanya adalah untuk mengikat 4 port GigE ke dalam trunk tunggal yang membawa 802.1q traffic yang ditandai. Saya bisa sejauh itu, namun saya mengalami masalah aneh. Tapi pertama-tama, sebuah diagram.

----------       ----------  1GbE trunks 
|        | 10GbE |        | ------------- --------
|  SW1   |-------|   SW2  | ------------- | VM1  |
|        |       |        | ------------- --------
----------       ----------
     |                |  1GbE  -----------
     | 1GbE           |--------| client2 |
     |                         -----------
----------
|        | 1GbE -----------
|  SW3   |------| client1 |
|        |      -----------
----------

Semua sakelar adalah sakelar HP ProCurve 2910al dan tidak ditumpuk. Client2 dalam diagram di atas adalah dalam VLAN yang sama dengan VM1. Client1 berada dalam VLAN yang berbeda. Untuk mesin VM (CentOS 6) baik iptables dan SELinux telah dinonaktifkan.

Masalah saya adalah bahwa ketika trunking terlibat, lalu lintas jaringan dua arah tidak mungkin ketika berbicara dengan salah satu mesin Klien. TCPDUMP menunjukkan bahwa ping diterima oleh mereka dan paket ECHO REPLY dikirim, tetapi host VM tidak pernah melihatnya. Pada saat yang sama, jika saya mencoba melakukan ping VM dari mesin klien, itu juga tidak berfungsi. Faktanya saya tidak bisa melakukan ping client2, yang berada di subnet yang sama, menunjukkan ada sesuatu yang edan di lapisan jaringan di suatu tempat.

Anehnya, dari host VM saya bisa ping IP gateway pada salah satu switch. Jika saya menggunakan antarmuka tunggal semuanya bekerja dengan baik dengan dan tanpa penandaan VLAN. Jika saya hanya mengikat satu antarmuka dan mengaktifkan penandaan VLAN pada antarmuka itu, saya bisa pergi ke mana saja. Bangun trunk, dan saya terbatas pada switch-fabric.

Jenis bagasi sepertinya tidak masalah. Saat ini mereka dikonfigurasikan dengan mode 0 trunks (balance-rr), meskipun menggunakan LACP / 802.1qa berperilaku dengan cara yang sama.

vlan 70 
   name "Virtualization Subnet" 
   untagged 35,36,38,40 
   tagged Trk1-Trk2,Trk5,Trk8 
   no ip address 
   jumbo 
   exit 

Itu konfigurasi VLAN pada SW2 di sana. Definisi VLAN 70 SW1 memiliki "alamat IP" yang ditentukan di atasnya. Cuplikan di atas berada dalam mode sepenuhnya tidak terbongkar. Ketika saya belalai:

trunk 35-36,38,40 Trk16 trunk
vlan 70 
   name "Virtualization Subnet" 
   tagged Trk1-Trk2,Trk5,Trk8,Trk16
   no ip address 
   jumbo 
   exit 

Versi 802.1qa / LACP memperdagangkan definisi trunk untuk trunk 35-36,38,40 Trk16 lacptetapi seperti yang saya katakan, tidak mengubah presentasi masalah.

Client2 sebenarnya terhubung ke SW1, tetapi meletakkannya di sana di bagan akan membuat format lebih sulit. Bagaimanapun, satu-satunya hal dalam bait Antarmuka adalah namearahan; terdaftar sebagai untaggedport di stanza vlan 70 untuk SW1.

Apa yang saya lewatkan?


Bisakah Anda memposting stanza switch VLAN milik Procurve Anda? Dan juga port apa yang hypervisor (alias VM) 1, klien 1 & 2 gunakan?
jftuga

@ jftuga The bait telah dimasukkan.
sysadmin1138

Untuk switch sw1, 2,3 semua port trunk'd uplink (ke switch lain) ditandai di vlan 70? Juga, apa yang ditunjukkan tracert kepada Anda?
jftuga

@ jftuga Ya, semua tautan inter-switch trunk dan ditandai. SW3 TIDAK memiliki VLAN 70 di atasnya. Traceroute menunjukkan sedikit ketertarikan, jejak mati pada saat itu akan sampai ke host VM. Juga, dari dalam saklar itu sendiri saya tidak bisa ping alamat IP host VM ketika trunked. Saya akan melihat apakah saya bisa mendapatkan sesuatu di tempat untuk mengendus set port berbatang.
sysadmin1138

Anda mengatakan bahwa ini adalah VM, seperti di Virtual Machine? Apakah Anda menjalankan ini pada ESX (i)?
pauska

Jawaban:


7

Setelah perdebatan panjang dalam obrolan yang melibatkan MikeyB , Pauska , dan ChrisS , masalah akhirnya menjadi dua kali lipat:

  1. Bug yang mungkin ada di CentOS 6 tidak mengubah opsi modul untuk bondingmodul sebagai bagian dari service network restart, jadi itu tidak melacak perubahan saya antara mode LACP (4) dan roundrobin (0).
  2. Mode Round-Robin tidak suka bekerja dengan sakelar ProCurve.

Setelah saya memaksa antarmuka terikat ke mode LACP / 802.1qa melalui perintah ini:

ifconfig bond0 down
echo "4" > /sys/class/net/bond0/bonding/mode
ifconfig bond0 up

Baik server dan saklar sedang berbicara. Pada saat itu, dimulai dengan hanya satu antarmuka yang diaktifkan pada sakelar, lalu lintas mulai bekerja secara normal. Mengaktifkan yang kedua, ketiga, dan akhirnya, keempat antarmuka semua membuat lalu lintas tetap berfungsi.

Pada akhirnya, mode LACP-lah yang membuat semuanya bekerja. Petunjuknya adalah bahwa mode round-robin bekerja ketika hanya ada satu switch-port yang diaktifkan di Trunk. Server selamat dari reboot dan muncul dalam mode yang benar. Namun, a service network restarttidak menyebabkan MODE="4"bagian dari ifcfg-bond0file masuk /etc/sysconfig/network-scripts/berlaku. Jika mode itu berubah, itu akan tetap seperti apa yang ditetapkan saat boot (atau lebih mungkin, waktu memuat bondingmodul dari modul).


Senang membantu :)
MikeyB

Senang melihat Anda memperbaiki ini.
jftuga

Pertanyaan dan jawaban yang sangat profesional. Terikat untuk membantu seseorang.
artifex

0

Anda memiliki konfigurasi Anda:

trunk 35-36,38,40 Trk16 trunk
vlan 70 
   name "Virtualization Subnet" 
   tagged Trk1-Trk2,Trk5,Trk8,Trk16
   no ip address 
   jumbo 
   exit 

Bukankah itu seharusnya:

   untagged Trk16
   tagged Trk1-Trk2,Trk5,Trk8

Nah, ada kesalahan dalam posting asli, tetapi tidak apa yang Anda sarankan. Di bawah konfigurasi yang tidak dibuka harus ada "Trk16 yang tidak ditandai" pada vlan 70.
pauska

Saya sudah mencoba varian itu juga. Kedua varian melakukan cara yang sama, tidak berfungsi. Menggunakan untagged 35-36,38,40dan tagged 35-36,38,40...keduanya berfungsi selama saya tidak mencoba untuk menjumlahkan antarmuka pada server Linux. untagged Trk16dan tagged Trk16...keduanya tidak bekerja.
sysadmin1138

Menjalankan Xen? Apakah Centos 6 masih muck dengan definisi antarmuka? Saya ingat masalah yang saya alami di mana antarmuka vlan dibuat dari antarmuka yang salah (fisik bukan jembatan atau sebaliknya) dan hal-hal aneh terjadi.
MikeyB
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.