null

Локализация проблемы для probe-based IPMP в Solaris

Недавно Илья Перминов писал о новой замечательной утилите 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

К списку статей

 

Интересуюсь по большей части системным анализом программного обеспечения: поиском багов и анализом неисправностей, а также системным программированием (и не оставляю надежд запилить свою операционку, хотя нехватка времени сказывается :) ). Программированием увлекаюсь с 12 лет, но так уж получилось, что стал я инженером.

Основная сфера моей деятельности связана с поддержкой Solaris и оборудования Sun/Oracle, хотя в последнее время к ним прибавились технологии виртуализации (линейка Citrix Xen) и всякое разное от IBM - от xSeries до Power. Учусь на кафедре Вычислительной Техники НИУ ИТМО.

See you...out there!

http://www.facebook.com/profile.php?id=100001947776045
https://twitter.com/AnnoyingBugs