IPMI SOL кто-нибудь наверняка должен знать...

SCIF32

Решил побаловаться с SOL в IPMI.
настроил, как описано в http://publib.boulder.ibm.com/infocenter/lnxinfo/v3r0m0/inde...
+ использовал автоматическую генерилку настроек bmclanconf
но не получается присоединиться удаленно к машине
как продиагностировать - запущен ли SOL на удаленной машине? (доступа к другим машинам из той же подсети нету)
локальные команды
ipmitool mc info
ipmitool channel info
ipmitool lan print
выдают что все вроде настроено правильно
при попытке удаленно присоединиться пишет, что вообще не может установить соединение.
tcpdump локально запущенный на машине с IPMI показывают, что к нему приходят пакеты на 623 порт (должен он это показывать, не так ли?)
правильно ли я понимаю, что настройки IP-шника и сети в IPMI могут совпадать с настройками интерфейса?

vall

правильно ли я понимаю, что настройки IP-шника и сети в IPMI могут совпадать с настройками интерфейса?

имхо нет, вроде там даже мак другой

SCIF32

по спецификации, или это плохо для безопасности (или еще что-то)?

vall

АФАИК чтоб не городить недюжий интеллект для разделения трафика ipmi интерфейс имеет свой мак, соответственно вешать туда такую-же ip несколько странно.
но сам я эту машинерию не настраивал.

SCIF32

хм, тогда странно, что bmclanconf
автоматически сгенерил параметры сети, дублирующие сетевой интерфейс

tata2410

это нормально, роут он ставит тот же, что и у системы, а вот если и ип совпали - тогда странно.

tokuchu

по спецификации, или это плохо для безопасности (или еще что-то)?

Да просто это отдельный компьютер внутри твоего компьютера, можно сказать. Было бы странно, если бы настройки доступа к нему зависели от настроек основного компьютера. Т.к. он должен быть доступен даже тогда, когда основной выключен или у него адрес может быть не настроен вообще.

SCIF32

да, кстати, проблема была действительно в ip-шниках
да я не про зависимость, а про возможность настройки без дополнительного ip-шника.
например, технически не вижу ничего сложного, что бы зохавывыть только трафик с 623-го порта, а с остальным ничего не делать, при этом не мешая нормальной работе основной сетевухи
не вижу я проблем с коммутацией пакетиков, если на одном конце с одним маком сидят два компа, но один из них "не высовывается" - или проблемы должны быть?
такое чувство, что я явно чего-то не понимаю в уровне IP...

Sharp

Ты чего-то не понимаешь не в IP, а в Ethernet-е.
Когда есть два компа с одним маком и один из них не высовывается, это называется или VRRP, или CARP.
В любом случае, это некоторая надстройка, которую должны понимать оба этих компьютера. Поэтому в 95% случаях такое невозможно.

yroslavasako

например, технически не вижу ничего сложного, что бы зохавывыть только трафик с 623-го порта, а с остальным ничего не делать, при этом не мешая нормальной работе основной сетевухи
такое чувство, что я явно чего-то не понимаю в уровне IP...

На уровне IP нету портов.

tokuchu

да я не про зависимость, а про возможность настройки без дополнительного ip-шника.

Так как раз из независимости и следует, что адреса нужны разные.

например, технически не вижу ничего сложного, что бы зохавывыть только трафик с 623-го порта, а с остальным ничего не делать, при этом не мешая нормальной работе основной сетевухи
не вижу я проблем с коммутацией пакетиков, если на одном конце с одним маком сидят два компа, но один из них "не высовывается" - или проблемы должны быть?

Ну теоретически такой огород можно нагородить, но возникает много вопросов. Например, получается, что наш сервер сам не сможет воспользоваться 623-м портом. Потом кто из них должен отвечать на ICMP? И как в таком случае проверить другого? Потом у других может быть портебность выделить интерфейс управления в отдельную сеть — и как в этом случае они будут отделяться? Что делать в том случае, если компьютер получает адрес по DHCP? И куча подобных.
Вообще, я слышал, что есть какие-то извращения, где один совмещённый сетевой порт, но там ip-адреса всё равно разные. Там то ли по MAC-адресу оно разделяет. То ли влан определённый выдёргивает. Сейчас уже не помню.

SCIF32

по идее все это можно разрулить, если настроить адреса статически и пользоваться rmcp_ping-ом.
про "совмещенный порт" только не понял, что ты имел ввиду под этим понятием

tokuchu

по идее все это можно разрулить, если настроить адреса статически и пользоваться rmcp_ping-ом.

А если кто-то не хочет статически? И опять же ICMP — это ядро отвечает, а на rmcp будет сервис управления отвечать. Нельзя продиагностировать если сервис повис, хотя это больше для разработчиков этого сервиса нужно.

про "совмещенный порт" только не понял, что ты имел ввиду под этим понятием

Ну порт, через который управление компом идёт, он не отдельно, а только 1 сетевуха у компа, а там уже разделение идёт логическое.

SCIF32

ну я не про то, что именно так должно быть, и так нужно настраивать.
а про возможность настроить систему так, чтобы все висело на одном ip, если по-другому никак нельзя.
надо было бы попробовать, да уже все настроил так, что работает - ломать не хочется.
будем считать, что это геморно и не нужно )
про один порт - так это вполне нормальная ситуация для Ethernet. в сетях на основе хабов тоже физического разделения нет - пакеты всем раздаются.
а на уровне интерфейса разделение идет стандартно - по MAC-адресам.

tokuchu

про один порт - так это вполне нормальная ситуация для Ethernet. в сетях на основе хабов тоже физического разделения нет - пакеты всем раздаются.
а на уровне интерфейса разделение идет стандартно - по MAC-адресам.

Я-то знаю про хабы и прочее. Что можно по MAC-адресам разделить. Просто в этом случае проблема в том, что в таком случае тебе нужно подключить 2 компьютера к сети, а они образно говоря висят на одном хабе и сконфигурировать (если там по MAC разделение) ты его не сможешь. Имеется в виду, что не можешь на одном порту засунуть одни сети, вланы и пр., а на другой порт — другие. Поэтому когда они раздельные, то в этом смысле проще. А уж внешним коммутатором их объединить (если понадобится) никогда не поздно будет.