Va bene - sto combattendo questo per almeno 20 ore consecutive .. Scusate se questo sembra un lungo sfogo, o un post sul blog, ma sto arrivando al punto di esaurimento.
Quindi, ecco l'affare. Stiamo usando i sistemi di bilanciamento del carico KEMP, che utilizza UCARP (un clone Linux di CARP, che è un clone VRRP) per il battito cardiaco HA e gli stati persistenti. Vogliamo utilizzare IGMP nel nostro ambiente per prevenire inondazioni nel data center.
Abbiamo due switch Dell PowerConnect 8124F con SW 5.1.1.7 che agiscono come top-of-rack. Questi due sono collegati a una coppia sovrapposta di Cisco 3750-X, che è il nostro core.
I problemi sono iniziati quando abbiamo eseguito l'aggiornamento a PowerConnect 5.1.x, dove apparentemente non sono riusciti a lasciare lo snooping IGMP a meno che tu non lo dica diversamente. Ed ecco, i nostri sistemi di bilanciamento del carico sono andati nel cervello diviso, causando ogni sorta di caldo divertimento fuzzy.
- Se disabilito lo snooping IGMP sulla VLAN in cui i bilanciatori del carico non eseguono il multicast, non accade nulla, il multicast è ancora morto
- Se imposto IP PIM sul nostro core, gli switch PowerConnect lo vedono sulla stessa VLAN, ma ancora nessun traffico multicast
- Se abilito l'inondazione di tutto il traffico multicast non registrato, continua a non fare nulla.
- Se disabilito lo snooping IGMP a livello globale sugli switch PowerConnect, tutto il traffico multicast funziona. Funziona così bene che il traffico multicast viene riversato su ogni singola porta con lo stesso tag VLAN. Meraviglioso.
Ho notato alcune strane voci dell'indirizzo MAC sulla VLAN nel nostro core:
coresw#sh mac address-table vlan 367 | include 5e00
367 0000.5e00.0101 DYNAMIC Po13 seq_no:0
E penso .. Non è l'indirizzo multicast? Perché non è questo nel "multicast sh-address-table"?
coresw#sh mac address-table multicast vlan 367
Vlan Mac Address Type Ports
---- ----------- ---- -----
coresw#
E poi ho letto questo nella guida della CLI di PowerConnect:
Il traffico multicast è il traffico destinato a un gruppo host. I gruppi host sono identificati dall'indirizzo MAC di destinazione, ovvero l'intervallo 01: 00: 5e: 00: 00: 00-01: 00: 5e: 7f: ff: ff: ff per il traffico multicast IPv4 o 33: 33: xx: xx : xx: xx per traffico multicast IPv6.
Sembra che ci manchi uno "01" all'inizio dell'indirizzo MAC, no? La voce MAC dinamica sopra inizia con "00". A questo punto sto pensando di chiamare KEMP e far loro sapere che il loro prodotto è orribilmente mal configurato. Ma poi vado a leggere la RFC per VRRP - ed ecco:
L'indirizzo MAC del router virtuale associato a un router virtuale è un indirizzo MAC IEEE 802 nel seguente formato:
Caso IPv4: 00-00-5E-00-01- {VRID} (in esadecimale, in ordine di bit standard Internet)
Bene, quindi gli switch normalmente non raccolgono l'intervallo di indirizzi mac multicast per VRRP. Bene, configuriamo un gruppo host statico sugli switch Dell. No.
Immissione non valida: l'indirizzo MAC multicast deve essere nel formato 01XX: XXXX: XXXX
OK quindi .. Passaggio successivo, prova ad aggiungere una voce mac statica:
osl-sys-swrack03(config)#mac address-table multicast ?
forbidden forbid adding specific multicast addresses to
specific ports.
osl-sys-swrack03(config)#
Quindi - nessun modo per configurare una voce MAC statica multicast. Se provo a fare lo stesso con una normale voce MAC statica, posso associarlo a una sola porta: questo cluster di bilanciamento del carico viene eseguito su 4 diverse porte da 10 gig.
Aggiornamento : sembra esserci un po 'di confusione riguardo agli indirizzi MAC. 172.30.1.0/24 è la rete di bilanciamento del carico frontale. 172.30.1.6 è il VIP condiviso predefinito per il cluster, .7 è l'IP di gestione per il primo bilanciamento del carico e .8 è per il secondo bilanciamento del carico. Tutti gli altri indirizzi (30, 40, 70, 80 ecc.) Sono tutti VIP con diversi servizi. Quando si verifica un failover, tutti i VIP cambiano il loro indirizzo MAC nel secondo indirizzo MAC fisico del LB. L'indirizzo multicast nella tabella in basso non cambia.
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
E questa è la storia. Cosa diavolo ho intenzione di fare con questo?
What on earth am I going to do with this?<- Tequila. Un sacco.