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.Jawaban:
Saya bisa menyelesaikan masalah ini. Pada Kemp (dengan pasangan HA) Anda memiliki opsi untuk menggunakan "Alamat MAC Virtual". Jika kotak ini tidak dicentang, maka MAC dari load balancer VIP adalah antarmuka fisik unit Kemp yang aktif. Jika kotak ini dicentang, maka alamat MAC VIP adalah MAC VRRP. Seperti yang Anda sebutkan di atas VRRP RFC menyatakan bahwa MAC "00:00" {blah} dengan oktet terakhir menjadi Router ID. ID default Kemp HA [router] adalah 01. Pada Powerconnects saya menggunakan Firmware 5.1.xx Saya tidak menggunakan VRRP tapi saya menjalankan beberapa jejak dan menetapkan bahwa Powerconnect akan menjatuhkan frame VRRP jika ID router sama seperti itu sendiri. Mereka melakukan ini BAHKAN jika VRRP tidak dikonfigurasi dan dalam mode itu mereka default ke 01. Jadi mengubah ID router Kemp HA ke sesuatu seperti 22 (0x16) menghasilkan semuanya berfungsi.
sumber
Alamat multicast yang Anda cari adalah 224.0.0.18 [mac: 01005e.000012]. Itu adalah saluran kontrol untuk semua node VRRP. [sunting] Kecuali KEMP mengubah kode, CARP (UCARP) berasal lalu lintas menggunakan VRRP unicast MAC [00005e.0001xx] - di situlah sebuah saklar secara alami akan mempelajarinya.
Jika Anda tidak memiliki querier di jaringan (mungkin di setiap segmen), maka switch Anda pada akhirnya akan lupa di mana grup berada - host tidak mengirim keanggotaan berkala kecuali diminta. [edit: Bergantung pada konfigurasi, sebuah saklar dapat menjatuhkan multicast yang tidak diketahui, vs. flooding.] Itu bisa menjadi querier khusus (mengirimkan paket, tidak peduli dengan jawaban apa pun), atau lebih umum router multicast dalam infrastruktur Anda . Dalam kasus sederhana ini, querier adalah semua yang diperlukan karena pesan VRRP dilarang melintasi segmen.
Saya tidak terbiasa dengan switch Dell, jadi saya tidak tahu apa perintah cli yang Anda butuhkan.
[MEMPERBARUI]
Itu bukan mac multicast. Itulah sumber MAC unicast dari lalu lintas multicast. Mac multicast tidak akan muncul di tabel alamat mac. Itu dalam tabel grup multicast. Cisco IOS memiliki
show mac-address-table multicast(tidak menunjukkan apa pun di router saya) danshow ip igmp groups(menunjukkan 3 grup). Router itu diatur ke mode jarang; switch nortel dan cisco melihatnya sebagai querier.Dan metode KEMP sangat cacat dengan menggunakan host NIC MAC untuk alamat virtual. Dalam kasus Anda, 5004 milik nic. Ketika 5004 menghilang, semua orang masih akan memiliki "IP: 6 == MAC: 5004" di tabel mereka; mereka akan terus mencoba berbicara dengan tuan rumah yang mati sampai entri itu diganti. KEMP jelas-jelas berjudi untuk mendapatkan penghargaan gratis dari semua yang ada di jaringan. HSRP, VRRP, dan CARP yang dirancang OpenBSD semuanya menggunakan MAC virtual karena alasan ini. (mereka tampaknya gagal meretas UCARP untuk menggunakan nic mac daripada VRRP virtual mac saat mentransmisikan lalu lintas multcast.)
Mengingat mereka peretasan dari UCARP, apakah Anda yakin itu menggunakan multicast?
sumber
show ip igmp snooping querier vlan 367untuk cisco)