Baiklah - telah berjuang ini selama setidaknya 20 jam berturut-turut .. Maaf jika ini sepertinya kata-kata kasar yang panjang, atau posting blog, tapi saya sampai pada titik kelelahan.
Jadi, inilah kesepakatannya. Kami menggunakan penyeimbang beban KEMP, yang menggunakan UCARP (klon Linux dari CARP, yang merupakan klon VRRP) untuk kondisi detak jantung HA dan persisten. Kami ingin memanfaatkan IGMP di lingkungan kami untuk mencegah banjir melintasi pusat data.
Kami memiliki dua sakelar Dell PowerConnect 8124F yang menjalankan SW 5.1.1.7 yang bertindak sebagai yang terbaik. Keduanya terhubung ke pasangan Cisco 3750-X yang bertumpuk, yang merupakan inti kami.
Masalahnya dimulai ketika kami memutakhirkan ke PowerConnect 5.1.x, di mana mereka tampaknya default untuk membiarkan IGMP mengintai kecuali Anda memberi tahu sebaliknya. Dan lihat - penyeimbang beban kami masuk ke otak terbelah, menyebabkan segala macam kesenangan fuzzy hangat.
- Jika saya menonaktifkan pengintaian IGMP pada VLAN di mana penyeimbang beban tidak melakukan multicast, multicast masih mati
- Jika saya mengatur PIM IP pada inti kami, sakelar PowerConnect melihatnya pada VLAN yang sama, tetapi masih tidak ada lalu lintas multicast
- Jika saya mengaktifkan banjir semua lalu lintas multicast yang tidak terdaftar, ia tetap tidak melakukan apa-apa.
- Jika saya menonaktifkan pengintaian IGMP secara global pada sakelar PowerConnect, semua lalu lintas multicast berfungsi. Ini bekerja sangat baik, sehingga kita mendapatkan lalu lintas multicast membanjiri setiap port yang memiliki tag VLAN yang sama. Hebat.
Saya perhatikan beberapa entri alamat MAC yang aneh pada VLAN di inti kami:
coresw#sh mac address-table vlan 367 | include 5e00
367 0000.5e00.0101 DYNAMIC Po13 seq_no:0
Dan saya pikir .. Bukankah itu alamat multicast? Mengapa ini tidak ada di "sh mac address-table multicast"?
coresw#sh mac address-table multicast vlan 367
Vlan Mac Address Type Ports
---- ----------- ---- -----
coresw#
Dan kemudian saya membaca ini di panduan CLI PowerConnect:
Lalu lintas multicast adalah lalu lintas yang diperuntukkan bagi grup host. Grup host diidentifikasi oleh alamat MAC tujuan, yaitu kisaran 01: 00: 5e: 00: 00-01: 00: 5e: 7f: ff: ff: ff untuk lalu lintas multicast IPv4 atau 33: 33: xx: xx : xx: xx untuk lalu lintas multicast IPv6.
Sepertinya kita kehilangan "01" di awal alamat MAC, bukan? Entri MAC dinamis di atas dimulai dengan "00". Pada titik ini saya sedang berpikir untuk memanggil KEMP, dan memberi tahu mereka bahwa produk mereka salah konfigurasi. Tapi kemudian saya membaca RFC untuk VRRP - dan lihat:
Alamat MAC router virtual yang terkait dengan router virtual adalah Alamat MAC IEEE 802 dalam format berikut:
Kasing IPv4: 00-00-5E-00-01- {VRID} (dalam hex, dalam urutan bit standar Internet)
Baiklah - jadi switch biasanya tidak mengambil kisaran alamat mac multicast untuk VRRP. Baik, mari kita mengkonfigurasi grup host statis pada switch Dell. Nggak.
Input tidak valid: Alamat MAC Multicast harus dalam format 01XX: XXXX: XXXX
Oke kalau begitu .. Langkah selanjutnya, coba tambahkan entri mac statis:
osl-sys-swrack03(config)#mac address-table multicast ?
forbidden forbid adding specific multicast addresses to
specific ports.
osl-sys-swrack03(config)#
Jadi - tidak ada cara untuk mengkonfigurasi entri MAC multicast statis. Jika saya mencoba melakukan hal yang sama dengan entri MAC statis biasa, saya hanya dapat mengikatnya ke satu port - cluster penyeimbang beban ini berjalan di 4 port 10 gig yang berbeda.
Pembaruan : Tampaknya ada beberapa kebingungan mengenai alamat MAC. 172.30.1.0/24 adalah jaringan loadbalancer yang menghadap ke depan. 172.30.1.6 adalah VIP bersama default untuk kluster, .7 adalah IP manajemen untuk penyeimbang beban pertama dan .8 untuk penyeimbang beban kedua. Semua alamat lain (30, 40, 70, 80 dll) semuanya VIP dengan layanan berbeda. Ketika failover terjadi, semua VIP mengubah alamat MAC mereka ke alamat MAC fisik LB kedua. Alamat multicast di tabel bawah tidak berubah.
coresw#sh ip arp vlan 367
Protocol Address Age (min) Hardware Addr Type Interface
Internet 172.30.1.6 78 0050.56b4.5004 ARPA Vlan367 <- VIP - Loadbalancer1 physical MAC
Internet 172.30.1.40 204 0050.56b4.5004 ARPA Vlan367 <- VIP - Loadbalancer1 physical MAC
Internet 172.30.1.80 167 0050.56b4.5004 ARPA Vlan367 <- VIP - Loadbalancer1 physical MAC
Internet 172.30.1.70 38 0050.56b4.5004 ARPA Vlan367 <- VIP - Loadbalancer1 physical MAC
Internet 172.30.1.66 12 0050.56b4.5004 ARPA Vlan367 <- VIP - Loadbalancer1 physical MAC
Internet 172.30.1.35 185 0050.56b4.5004 ARPA Vlan367 <- VIP - Loadbalancer1 physical MAC
Internet 172.30.1.60 97 0050.56b4.5004 ARPA Vlan367 <- VIP - Loadbalancer1 physical MAC
Internet 172.30.1.30 80 0050.56b4.5004 ARPA Vlan367 <- VIP - Loadbalancer1 physical MAC
Internet 172.30.1.61 33 0050.56b4.5004 ARPA Vlan367 <- VIP - Loadbalancer1 physical MAC
Internet 172.30.1.7 27 0050.56b4.5004 ARPA Vlan367 <- Management - Loadbalancer1 physical MAC
Internet 172.30.1.8 21 0050.56b4.08c2 ARPA Vlan367 <- Management - Loadbalancer2 physical MAC
osl-sys-coresw#sh mac address-table dynamic vlan 367
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
367 0000.5e00.0101 DYNAMIC Po13 seq_no:0 <- multicast HA mac (UCARP)
367 0050.56b4.08c2 DYNAMIC Po13 seq_no:0 <- Loadbalancer1 physical MAC
367 0050.56b4.5004 DYNAMIC Po13 seq_no:0 <- Loadbalancer2 physical MAC
Dan begitulah ceritanya. Apa yang akan saya lakukan dengan ini?
What on earth am I going to do with this?<- Tequila. Banyak sekali.