Жила-была одна небольшая производственная площадка со своим скромным сетевым и серверным скарбом, к которому в один прекрасный момент присовокупили новый сервер HPE ProLiant DL380 Gen10 с контроллером удалённого управления iLO5. При первичной настройке сервера местные специалисты обратили внимание на то, что сетевой интерфейс iLO, настроенный на получение IP адресации с DHCP, теряет подключение к сети через несколько минут после начала работы. И тут начались хождения по мукам…
Переключение контроллера iLO в другие порты коммутатора, замена патч-кордов и прочие первичные проверки на ситуацию никак не повлияли. Подключили к тому же порту коммутатора ноутбук с Windows, получили адрес по DHCP, всё работает без проблем. А подключенные в соседние порты этого же коммутатора интерфейсы управления СХД HPE MSA работали также без каких-либо нареканий.
Начали подозревать, что новый сервер какой-то "не такой", поэтому было открыто обращение в тех.поддержку HPE. Анализ аппаратных логов IML/iLO тех.поддержкой явных проблем в железе сервера не выявил.
Выполнили перепрошивку firmware компонент сервера, в том числе iLO … ничего не изменилось.
Выполнили сохранение лицензионных данных iLO5 согласно статьи "How to Backup, Restore and Recover an iLO License Key?". Затем выполнили сброс настроек iLO5 по статье "Managing iLO Reboots, Factory Reset, and NMI". После этого проблема снова воспроизвелась, то есть контроллер iLO5 снова потерялся через ~5 минут подключения к сети.
Так как порт iLO5 интегрирован в материнскую плату сервера, тех.поддержкой HPE уровня L2 был принято решение о замене материнской платы.
С мыслями "ну теперь то всё наладится", провели хлопотную замену материнской платы сервера. Однако, к нашему большому удивлению, после замены материнской платы ситуация с потерей сети в iLO снова воспроизвелась. Тут стало очевидно, что "дело было не в бобине".
К решению проблемы на площадке подключили специалиста из телеком-блока. Он подключился к коммутатору с проблемным сервером и начал смотреть, что происходит в сети Wireshark-ом. Далее, красочное описание ситуации с его слов …
Итак, действующие лица сегодняшнего спектакля:
- 10.1.28.158 - мой компьютер;
- 10.1.85.12 - iLO интерфейс сервера HPE ProLiant;
- Шлюз площадки с MAC адресом *.6e68
- 10.1.83.109 с MAC адресом *.73df – мелкий, но вредный коммутатор Cisco SF352-08P.
Действие 1.
Я пингую интерфейс сервера и от него идут ответы. MAC адрес назначения - местный шлюз. Всё нормально, как и должно быть. Так продолжается несколько минут.
Действие 2.
На сцену выходит Cisco SF352-08P и каждые 15 минут орёт на всю сеть мультикастом: "Я готов стать шлюзом любому, кто пожелает!" (пакет 3). Это протокол IRDP. Я не знаю, зачем он это делает, так как на нём даже не настроен маршрут по умолчанию: он управляется только из локальной сети.
Но iLO на сервере, несмотря на то, что шлюз у него уже настроен, тут же хватается за эту возможность.
И вот от меня приходит очередной запрос ICMP (пакет 4), и iLO в спешке начинает выяснять, где у него новый шлюз (пакет 5). От коммутатора приходит ответ (6), и iLO отправляет ответ на пинг в сторону коммутатора (7). Обратите внимание на MAC адрес получателя: *.73df.
А коммутатор вообще не знает ни одного маршрута; он начинает краснеть, шаркать ножкой и в конце концов признаётся, что понятия не имеет, куда отправлять этот пакет (8). Но iLO на это уже не обращает внимания и продолжает слать пакеты на коммутатор.
Ради эксперимента я указал на коммутаторе маршрут по умолчанию, и всё заработало как надо. Теперь интерфейс iLO пингуется стабильно. Я не знаю, как должны реагировать на пакеты ICMP Router Advertisement интерфейсы, где уже прописан шлюз. Но судя по тому, что в сети они больше никому не мешают, все приличные интерфейсы их игнорируют. Думаю, можно задать вопрос об этом HPE. Но, предполагаю, они ответят что-то вроде "Это не баг, это фича – можно воткнуть iLO в любую дырку, и оно там заработает без настройки". В общем, у меня всё. Занавес.
В общем и целом коллеги из Телекома пришли к выводу о том, что в данной ситуации корнем проблемы является не совсем корректное поведение коммутатора Cisco SF352-08P. На мысли о том, что описанная проблема присуща разным моделям коммутаторов Cisco 300 серии, наводят и похожие свидетельства очевидцев.
В качестве варианта для окончательного решения проблемы было использовано отключение включенного по умолчанию функционала маршрутизации в коммутаторе Cisco SF352 конфигурационной командой типа "no ip routing".
Интересным во всей этой истории является то, что iLO так легко поддаётся объявлению маршрутизатора по ICMP. Понимая это, в злонамеренных целях можно целенаправленно протащить трафик iLO через нужный хост или использовать для DoS-атак в сегменте локальной сети.
RSS - Записи
Добавить комментарий