Недавно Илья Перминов писал о новой замечательной утилите ipmpstat, появившейся в OpenSolaris. В Solaris 10 мониторинг состояния IPMP увы ограничен, и в этой статье я рассмотрю, каким образом все-таки можно локализовать проблему с probe-based IPMP.
В первую очередь необходимо выявить текущую конфигурацию IPMP: интерфейсы хоста, участвующие в группе и цели IPMP, на которые шлются ICMP-пакеты. Выполним две команды: ifconfig -a и netstat -rn:
bash-3.00# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
bge0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.50.13 netmask ffffff00 broadcast 192.168.50.255
groupname ipmptest
ether 0:3:ba:60:3b:71
bge0:1: flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> mtu 1500 index 2
inet 192.168.50.14 netmask ffffff00 broadcast 192.168.50.255
bge1: flags=69040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER,STANDBY,INACTIVE> mtu 1500 index 3
inet 192.168.50.15 netmask ffffff00 broadcast 192.168.50.255
groupname ipmptest
ether 0:3:ba:60:3b:72
bash-3.00# netstat -rn
Routing Table: IPv4
Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ---------- ---------
default 192.168.50.1 UG 1 433
192.168.50.0 192.168.50.13 U 1 2 bge0
192.168.50.0 192.168.50.13 U 1 0 bge0:1
192.168.50.0 192.168.50.13 U 1 2 bge1
192.168.50.2 192.168.50.2 UGH 1 0
224.0.0.0 192.168.50.13 U 1 0 bge0
127.0.0.1 127.0.0.1 UH 1 124 lo0
В выводе ifconfig следует обратить на тег group - имя группы. Очевидно, что в него входят интерфейсы bge0 и bge1. Рассмотрим флаги интерфейсов.
-
DEPRECATED и NOFAILOVER устанавливаются на интерфейсы, задача которых - тестирование сети с помощью проб (ICMP-запросов). DEPRECATED запрещает пересылку IP-пакетов с интерфейса если это явно не указано (подробнее в man ifconfig).
-
STANDBY и INACTIVE используется в тех случаях, если не нужна балансировка нагрузок между интерфейсами, как это обычно бывает в IPMP.
Все остальные интерфейсы используются для передачи данных по сети.
Цели ipmp определяются статическими маршрутами - обычно в качестве цели выступает default router - 192.168.50.1. Однако, в данном случае мы имеем место с multi-targeted ipmp - еще одной целью является 192.168.50.2 (для него, очевидно Destination==Gateway). Добавим теперь еще одну цель, и сделаем недоступной:
bash-3.00# route add -host 192.168.50.21 192.168.50.21
add host 192.168.50.21: gateway 192.168.50.21
Чтобы проверить статистику in.mpathd нужно послать ему сигнал SIGUSR1. После этого in.mpathd выведет ее в syslog:
bash-3.00# pkill -USR1 in.mpathd
bash-3.00# dmesg | tail -20
<cut>
Aug 6 12:23:01 sf210 in.mpathd[24985]: [ID 942985 daemon.error] Missed sending total of 0 probes spread over 0 occurrences
Aug 6 12:23:01 sf210 in.mpathd[24985]: [ID 214330 daemon.error]
Aug 6 12:23:01 sf210 Probe stats on (inet bge1)
Aug 6 12:23:01 sf210 Number of probes sent 147
Aug 6 12:23:01 sf210 Number of probe acks received 135
Aug 6 12:23:01 sf210 Number of probes/acks lost 12
Aug 6 12:23:01 sf210 Number of valid unacknowled probes 0
Aug 6 12:23:01 sf210 Number of ambiguous probe acks received 0
Aug 6 12:23:01 sf210 in.mpathd[24985]: [ID 214330 daemon.error]
Aug 6 12:23:01 sf210 Probe stats on (inet bge0)
Aug 6 12:23:01 sf210 Number of probes sent 147
Aug 6 12:23:01 sf210 Number of probe acks received 130
Aug 6 12:23:01 sf210 Number of probes/acks lost 17
Aug 6 12:23:01 sf210 Number of valid unacknowled probes 0
Aug 6 12:23:01 sf210 Number of ambiguous probe acks received 0
Как видим, потерялось 12 ответов на пробы на интерфейсе bge0 и 17 на bge1. Увидеть потери можно используя snoop. При отсылке ICMP-запросов он увеличивает последовательно значение поля ICMP sequence number.
Увидеть, на какой из целей IPMP проявляется проблема можно используя snoop на проблемном хосте фильтруя по протоколу icmp и списку хостов:
bash-3.00# snoop -ta -d bge0 '(host tdcsrv or host tdcgate or host sf880) and icmp'
Using device bge0 (promiscuous mode)
12:28:39.80020 sf210-0 -> tdcsrv.tdc ICMP Echo request (ID: 39170 Sequence number: 384)
12:28:39.80064 tdcsrv.tdc -> sf210-0 ICMP Echo reply (ID: 39170 Sequence number: 384)
12:28:41.27021 sf210-0 -> tdcgate.tdc ICMP Echo request (ID: 39170 Sequence number: 385)
12:28:41.27049 tdcgate.tdc -> sf210-0 ICMP Echo reply (ID: 39170 Sequence number: 385)
12:28:42.85015 sf210-0 -> sf880.tdc ICMP Echo request (ID: 39170 Sequence number: 386)
12:28:44.00014 sf210-0 -> tdcsrv.tdc ICMP Echo request (ID: 39170 Sequence number: 387)
12:28:44.00051 tdcsrv.tdc -> sf210-0 ICMP Echo reply (ID: 39170 Sequence number: 387)
12:28:45.53016 sf210-0 -> tdcgate.tdc ICMP Echo request (ID: 39170 Sequence number: 388)
Видим что ответ на пробу с номером 386 не получено ответа. Теперь необходимо убедиться, что цель IPMP получает пробу - аналогичным образом выполнив snoop, но в качестве хостов указывая DEPRECATED-адреса нашей системы. Для tcpdump аналогичный синтаксис приведен ниже:
# tcpdump -i <имя интерфейса> -n \
'(host 192.168.50.14 and host 192.168.50.15)
and icmp[icmptype] == icmp-echo or icmp[icmptype] == icmp-echoreply'
После того, как мы узнали, с какой стороны поблема, можно анализировать arp-таблицы и настройки коммутаторов.
При возникновении более сложных ситуаций можно включить debug-режим в in.mpathd (выводиться информация будет на stdout).
bash-3.00# pkill -9 in.mpathd
bash-3.00# /usr/lib/inet/in.mpathd -d 4 2>&1 | tee /var/tmp/mpathd.log
и обращаться в службу технической поддержки.
Внимание! В кластерных конфигурациях вместо pkill -9 in.mpathd нужно останавливать соответствующую службу: svcadm disable network/multipath:cluster