Хорошо - я боролся с этим в течение по крайней мере 20 часов подряд. Извините, если это похоже на длинную напыщенную речь или сообщение в блоге, но я дошел до истощения.
Итак, вот сделка. Мы используем балансировщики нагрузки KEMP, которые используют UCARP (Linux-клон CARP, который является VRRP-клоном) для сердцебиения HA и постоянных состояний. Мы хотим использовать IGMP в нашей среде, чтобы предотвратить наводнения в центре обработки данных.
У нас есть два коммутатора Dell PowerConnect 8124F, работающие на ПО 5.1.1.7, которые работают в качестве верхней части стойки. Эти два подключены к пачке Cisco 3750-X, которая является нашим ядром.
Проблемы начались, когда мы обновили PowerConnect 5.1.x, где они, по-видимому, по умолчанию оставили IGMP-слежку включенной, если вы не укажете обратное. И вот - наши балансировщики нагрузки ушли в сплит-мозг, вызывая всевозможные теплые нечеткие забавы.
- Если я отключаю отслеживание IGMP в VLAN, где балансировщики нагрузки выполняют многоадресную рассылку, ничего не происходит, многоадресная рассылка все еще не работает
- Если я настрою IP PIM на нашем ядре, коммутаторы PowerConnect увидят его в той же VLAN, но по-прежнему не будут передавать многоадресный трафик.
- Если я включаю флуд весь незарегистрированный многоадресный трафик, он все равно ничего не делает.
- Если я отключаю отслеживание IGMP глобально на коммутаторах PowerConnect, весь многоадресный трафик работает. Он работает настолько хорошо, что мы получаем многоадресный трафик на каждый порт, имеющий одну и ту же VLAN-метку. Чудесно.
Я заметил некоторые странные записи MAC-адресов в VLAN в нашем ядре:
coresw#sh mac address-table vlan 367 | include 5e00
367 0000.5e00.0101 DYNAMIC Po13 seq_no:0
И я думаю .. Разве это не адрес многоадресной рассылки? Почему это не в "многоадресной таблице адресов sh mac"?
coresw#sh mac address-table multicast vlan 367
Vlan Mac Address Type Ports
---- ----------- ---- -----
coresw#
А потом я прочитал это в руководстве по PowerConnect CLI:
Многоадресный трафик - это трафик, предназначенный для группы узлов. Группы хостов идентифицируются по MAC-адресу назначения, то есть в диапазоне 01: 00: 5e: 00: 00: 00-01: 00: 5e: 7f: ff: ff: ff для многоадресного трафика IPv4 или 33: 33: xx: xx : xx: xx для многоадресного трафика IPv6.
Похоже, мы пропустили "01" в начале MAC-адреса, нет? Динамическая запись MAC выше начинается с «00». На данный момент я думаю о том, чтобы позвонить в KEMP и сообщить им, что их продукт ужасно неправильно настроен. Но тогда я иду читать RFC для VRRP - и вот:
MAC-адрес виртуального маршрутизатора, связанный с виртуальным маршрутизатором, представляет собой MAC-адрес IEEE 802 в следующем формате:
IPv4-кейс: 00-00-5E-00-01- {VRID} (в шестнадцатеричном формате, в стандартном порядке следования битов в Интернете)
Хорошо, так что коммутаторы обычно не выбирают диапазон MAC-адресов многоадресной рассылки для VRRP. Хорошо, давайте настроим статическую группу хостов на коммутаторах Dell. Нет.
Неверный ввод: MAC-адрес многоадресной рассылки должен иметь формат 01XX: XXXX: XXXX
Хорошо, тогда .. Следующий шаг, попробуйте добавить статическую запись Mac:
osl-sys-swrack03(config)#mac address-table multicast ?
forbidden forbid adding specific multicast addresses to
specific ports.
osl-sys-swrack03(config)#
Так что - нет способа настроить статическую многоадресную запись MAC. Если я пытаюсь сделать то же самое с обычной статической записью MAC, я могу привязать ее только к одному порту - этот кластер балансировки нагрузки работает через 4 разных порта по 10 гигабайт.
Обновление : Кажется, есть некоторая путаница относительно MAC-адресов. 172.30.1.0/24 - это фронтальная сеть балансировки нагрузки. 172.30.1.6 - это общий VIP по умолчанию для кластера, .7 - это IP-адрес управления для первого балансировщика нагрузки, а .8 - для второго балансировщика нагрузки. Все остальные адреса (30, 40, 70, 80 и т. Д.) Являются VIP-персонами с различными услугами на них. Когда происходит аварийное переключение, все VIP меняют свой MAC-адрес на физический MAC-адрес второго LB. Адрес многоадресной рассылки в нижней таблице не меняется.
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
И это история. Что я буду делать с этим?
What on earth am I going to do with this?
<- Текила. Многое из этого.