Хорошо - я боролся с этим в течение по крайней мере 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?<- Текила. Многое из этого.Ответы:
Я был в состоянии решить проблему. На Kemp (с парой HA) у вас есть возможность использовать «Виртуальный MAC-адрес». Если этот флажок не установлен, то MAC для балансировщика нагрузки VIP соответствует физическому интерфейсу активного модуля Kemp. Если этот флажок установлен, то MAC-адрес VIP является MAC-адресом VRRP. Как вы упомянули выше, RFC VRRP утверждает, что MAC является «00:00» {бла}, а последний октет является идентификатором маршрутизатора. По умолчанию идентификатор Kemp HA [router] равен 01. На моих Powerconnects с использованием прошивки 5.1.xx я не использую VRRP, но я провел несколько трассировок и определил, что Powerconnect пропустит кадр VRRP, если идентификатор маршрутизатора такой же, как у него самого. Они делают это ДАЖЕ, если VRRP не настроен, и в этом режиме они устанавливают значение по умолчанию 01. Поэтому изменение идентификатора маршрутизатора Kemp HA на что-то вроде 22 (0x16) приводит к тому, что все работает.
источник
Адрес многоадресной рассылки, который вы ищете: 224.0.0.18 [mac: 01005e.000012]. Это канал управления для всех узлов VRRP. [править] Если KEMP не изменил код, CARP (UCARP) отправляет трафик с использованием одноадресного MAC-адреса VRRP [00005e.0001xx] - вот где коммутатор, естественно, изучит его.
Если у вас нет опроса в сети (предположительно в каждом сегменте), то ваши коммутаторы в конечном итоге забудут, где находятся группы - хосты не отправляют периодические членства, если их не просят. [править: в зависимости от конфигурации, коммутатор может отбрасывать неизвестную многоадресную рассылку, а не затоплять.] Это может быть выделенный запрос (он отправляет пакет, он не заботится о каких-либо ответах) или чаще маршрутизатор многоадресной рассылки в вашей инфраструктуре , В этом простом случае запрос - это все, что требуется, поскольку сообщения VRRP в любом случае запрещены для пересечения сегментов.
Я не знаком с коммутаторами Dell, поэтому не знаю, какие команды cli вам нужны.
[ОБНОВИТЬ]
Это не мультикаст Mac. Это одноадресный MAC- источник многоадресного трафика. Многоадресный Mac не будет отображаться в таблице адресов Mac. Это в таблице групповой рассылки. Cisco IOS имеет
show mac-address-table multicast(ничего не показывает на моем маршрутизаторе) иshow ip igmp groups(показывает 3 группы). Этот маршрутизатор установлен в режим pim sparse-mode; Коммутаторы nortel и cisco видят в этом запрос.И метод KEMP глубоко испорчен использованием MAC-адреса хоста MAC для виртуальных адресов. В вашем случае 5004 принадлежит ник. Когда 5004 исчезнет, у всех все еще будет «IP: 6 == MAC: 5004» в их таблицах; они будут продолжать пытаться общаться с мертвым хостом, пока эта запись не будет заменена. KEMP, очевидно, делает ставку на бесплатную игру, которую уважают все в сети. HSRP, VRRP, и OpenBSD предназначен карп все использовать виртуальный MAC именно по этой причине. (они, похоже, не смогли взломать UCARP, чтобы использовать nic mac вместо виртуального mac VRRP при передаче своего мультикастового трафика.)
Учитывая, что они взломали UCARP, вы уверены, что он даже использует многоадресную рассылку?
источник
show ip igmp snooping querier vlan 367для cisco)