Keepalived: многоадресная и одноадресная рассылка
Я планирую развернуть несколько поддерживающих активностьмаршрутизаторов для поддержки плавающих IP-адресов для разных кластеров баз данных. План состоит в том, чтобы развернуть отдельный экземпляр VRRPв каждом кластере локально в соответствии с этимруководством, поэтому в каждом кластере будет только два VRRPмаршрутизатора/экземпляра.
Пакет keepalived, доступный в репозитории CentOS 6x, имеет версию 1.2.7, и кажется, что одноадресная рассылка не была частью основной кодовой базы keepalivedпримерно до версии 1.2.8. .
В1.
Интересно, могут ли несколько маршрутизаторов VRRPнаводнить сеть многоадресной рекламой и вызвать некоторые проблемы с производительностью? Вы бы порекомендовали использовать unicast в этом случае? Однако я заметил следующее предупреждение, связанное с одноадресной передачей ( Ref. ):
vrrp: отключить проверку работоспособности TTL для случая использования одноадресной рассылки. Чтобы защита от любого внедрения пакетов, VRRP обеспечивает проверку работоспособности TTL заголовка IP. Этот TTL ДОЛЖЕН быть равен 255 и означает, что оба отправитель и получатель подключены к одному и тому же сегменту Ethernet. В настоящее время с расширением unicast эта защита ДОЛЖНА быть отключена, поскольку VRRP реклама в основном будет проходить через разные сегменты сети.!!! ВНИМАНИЕ!!! При использовании VRRP в сценарии использования одноадресной передачи для защиты против любой инъекции пакетов лучше всего использовать IPSEC-AH auth, в противном случае вы подвергаетесь риску потенциальных злоумышленников!
В2.
Почему другие серверы в сети, не являющиеся членами группы многоадресной рассылки vrrp.mcast.net, все еще получают рекламу VRRP?
# netstat -g
IPv6/IPv4 Group Memberships
Interface RefCnt Group
--------------- ------ ---------------------
lo 1 all-systems.mcast.net
eth0 1 all-systems.mcast.net
eth1 1 all-systems.mcast.net
lo 1 ff02::1
eth0 1 ff02::1:ff33:2440
eth0 1 ff02::1
eth1 1 ff02::1:ff90:4d5b
eth1 1 ff02::1
-
# tcpdump -i eth1 -c 2 host vrrp.mcast.net
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
20:30:46.241228 IP 172.16.0.70 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 3, prio 1, authtype simple, intvl 1s, length 20
20:30:47.241372 IP 172.16.0.70 > vrrp.mcast.net: VRRPv2, Advertisement, vrid 3, prio 1, authtype simple, intvl 1s, length 20
2 packets captured
2 packets received by filter
0 packets dropped by kernel
Я предполагаю, что другим подходом было бы развертывание только одной пары маршрутизаторов VRRPи поддержка VIP для всех кластеров БД.
В1. Интересно, может ли несколько VRRP-маршрутизаторов наводнить сеть многоадресной рекламой и вызвать проблемы с производительностью? Вы бы порекомендовали использовать unicast в этом случае?
Никакое разумное количество VRRP-маршрутизаторов не должно вызывать проблем, даже если реклама выходит каждую секунду, это всего лишь один широковещательный пакет. Я бы не рекомендовал использовать одноадресную рассылку, потому что это делает настройку VRRP более хрупкой, чем должна быть, каждый раз, когда вам нужно перенастроить IP-адрес пира, вам нужно будет обновить конфигурацию других пиров, что может привести к простою. Тем не менее, я бы рекомендовал использовать IPSEC-AH даже в многоадресной среде, если только вам не требуется взаимодействие с оборудованием, которое не поддерживает этот тип аутентификации (имейте в виду, что аутентификация PASS бесполезна с точки зрения безопасности, IPSEC-AH — единственный безопасный тип аутентификации).
В2. Почему другие серверы в сети, не являющиеся членами группы многоадресной рассылки vrrp.mcast.net, все равно получают рекламу VRRP?
Многоадресный трафик, поступающий в широковещательный домен, (L2-соседние хосты), транслируется на все интерфейсы, если только ваше сетевое оборудование не настроено на поддержку многоадресной рассылки-и не учитывает запросы IGMP от ваших узлов. Часто по умолчанию сетевое оборудование не выполняет отслеживание IGMP и, следовательно, просто транслирует весь многоадресный трафик. Учитывая, что это всего несколько пакетов в секунду, я бы не слишком беспокоился. Принятие политики белого списка для вашего брандмауэра поможет вам изолировать нежелательный трафик, и с его помощью можно будет контролировать VRRP/AH+VRRP/IGMPv3.