IPv4 на EMC Mellanox SX6018: setnewip, поведение ifconfig, MAC и проверка маршрутов
Short answer
В этой OEM-консоли обнаружена форма setnewip dotted_ip_addr. После изменения адреса независимо проверяйте ifconfig -a, showif и route -n show. Исторический переход от .5 к .120 не записан полностью; сохранение после перезапуска не проверялось.
Verification note: Публикация подготовлена по предоставленному владельцем архиву от 2 ноября 2026 года. Редакция сверила целостность файлов и дословность 67 зарегистрированных лог-блоков; нового сеанса с устройством при подготовке публикации не выполнялось. Вставки с пометкой «Реальный лог» сохранены без изменения. Ссылки на исходные файлы обозначают редакционный архив, а не публичные загрузки.
Команда смены IP может завершиться без сообщения об ошибке и всё же не дать ожидаемого результата. На исследованном EMC Mellanox SX6018 обычный вызов ifconfig добавил маршрут к новой подсети, тогда как адрес интерфейса и показания собственного диагностического интерфейса ОС остались прежними. Этот случай полезен тем, что позволяет сравнить намерение оператора с несколькими независимыми проверками фактического состояния.
Материал относится к EMC SwitchOS 1.395, сборке от 2015-05-11, с полем Firmware Revision 9.9.1260. Приглашение консоли — Switch-A(4)>. Аппаратная идентификация, загрузка и VPD разобраны в первой статье. Сетевые действия выполнялись через последовательную консоль. Последующий сбор материала через MCP повторял команды просмотра на том же устройстве.
Как читать вставки. «Реальный лог» обозначает переданный устройством текст. Исторические фрагменты получены от оператора во время изменения настроек; свежие — непосредственно через MCP. Они подписаны раздельно. Важный пробел между двумя историческими фрагментами сохранён явно: промежуточных команд мы не придумываем. В публикуемом серийном номере шасси одинаково заменены две последние цифры; остальные числовые данные в логах не изменялись. В свежих блоках убраны ANSI-коды цвета и CR; исходные события сохранены в JSON (редакционный архив: evidence/live-capture.json).
В публичных материалах по этому семейству часто встречаются инструкции управления MLNX-OS. Для EMC-варианта различие программной среды подтверждается, например, обсуждением SX6018 на форуме NVIDIA. В нашей работе синтаксис команд уточнялся по фактическим ответам SwitchOS 1.395. Общие руководства по Unix нельзя использовать как доказательство того, что OEM-реализация полностью повторяет привычную сетевую утилиту.
Начальное состояние удобно получить командой showif. Она выводит не только IP, маску и broadcast, но и отдельную строку service processor address. При первой попытке разобраться с сетевыми командами консоль также показала собственную справку ifconfig и route.
НАЧАЛО РЕАЛЬНОГО ЛОГА · log-009
Пользовательский вывод в переданных оператором материалах, до смены адресов. Источник (редакционный архив: evidence/historical-excerpts.json).
Switch-A(4)> showif
addr=ac10ff78 mask=ffff0000 broadcast=ac10ffff
172.16.255.120 255.255.0.0 172.16.255.255
My address is class B
service processor address 172.16.255.252
Switch-A(4)> ifconfig
usage: ifconfig [ -a ] [ -A ] [ interface ]
[ address ] [ netmask mask ] [ broadcast mask ]
[ mtu n ] [ delete ] [ up ] [ down ]
Switch-A(4)> route
route: botched keyword: e
usage: route [ -nqv ] cmd [[ -<modifiers> ] args ]
keywords: get, add, change, delete, show, flush, monitor.
Switch-A(4)> env help
Command NOT recognized
Switch-A(4)>
КОНЕЦ РЕАЛЬНОГО ЛОГА · log-009
Начальный IP равен 172.16.255.120, маска — 255.255.0.0, broadcast — 172.16.255.255. Адрес service processor указан как 172.16.255.252. Это отдельное поле; считать его шлюзом по умолчанию оснований нет. Маршруты проверялись другой командой, и default route в показанных таблицах отсутствовал.
Вторая особенность — представление адресов в первой строке showif. Значение ac10ff78 соответствует четырём октетам 172, 16, 255 и 120; ffff0000 соответствует маске /16. Поэтому шестнадцатеричная и десятичная строки здесь согласуются. Такое сопоставление помогает заметить расхождение между отдельными средствами диагностики, если оно появится. Мы не предполагаем по названию поля наличие скрытого дополнительного адреса: это два представления одних показанных чисел.
Справка ifconfig выглядит знакомо: интерфейс, address, netmask, broadcast, mtu, delete, up и down. Однако знакомый список параметров не гарантирует привычного результата реализации. Первую команду изменения проверили сразу тремя средствами — ifconfig -a, showif и route -n show.
НАЧАЛО РЕАЛЬНОГО ЛОГА · log-010
Пользовательский вывод в переданных оператором материалах: неудачная замена первичного IP. Источник (редакционный архив: evidence/historical-excerpts.json).
Switch-A(4)> ifconfig eth0 192.168.0.120 netmask 255.255.255.0 broadcast 192.168.0.255
Switch-A(4)> ifconfig -a
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33224
inet 127.0.0.1 netmask 0xff000000
eth0: flags=843<UP,BROADCAST,RUNNING,SIMPLEX> mtu 1500
inet 172.16.255.120 netmask 0xffff0000 broadcast 172.16.255.255
Switch-A(4)> showif
addr=ac10ff78 mask=ffff0000 broadcast=ac10ffff
172.16.255.120 255.255.0.0 172.16.255.255
My address is class B
service processor address 172.16.255.252
Switch-A(4)> route -n show
Routing tables
Internet:
Destination Gateway Flags
127.0.0.1 127.0.0.1 UH
172.16.0.0 link#1 U
192.168.0.0 link#1 U
Switch-A(4)>
КОНЕЦ РЕАЛЬНОГО ЛОГА · log-010
Эта последовательность показывает конкретный результат: первичный адрес eth0 остался 172.16.255.120, маска — /16, service processor — 172.16.255.252. При этом в таблице появилась ещё одна непосредственно подключённая сеть 192.168.0.0 с link#1. Следовательно, команда не была полностью проигнорирована, но её результат не соответствовал цели заменить старую адресацию.
Мы не установили внутреннюю причину. У нас нет исходного кода OEM-реализации и трассировки её сетевых вызовов. Было бы преждевременно объяснять случившееся конкретным ioctl, отдельным сохранённым кэшем или автоматической службой, которая «вернула» настройки. В статье фиксируется наблюдаемое расхождение, а не выбранная наугад причина.
Также нельзя делать более сильное утверждение, что ifconfig на этой ОС вообще не умеет менять IP. Проверен один конкретный вызов с сочетанием адреса, маски и broadcast. Другие формы, порядок параметров и работа с несколькими адресами отдельно не исследовались. Такой уровень точности сохраняет ценность результата: другой оператор сможет проверить именно тот случай, который действительно был снят.
Полезная практическая деталь — route без аргументов в этом сеансе ответила строкой botched keyword: e. Почему она появилась, не установлено. Напротив, форма route -n show, указанная в подсказке самой программы, вывела таблицу. Текст ошибки сохранён в первом фрагменте, чтобы поведение OEM-консоли не выглядело более аккуратным, чем в действительности.
После этого внимание переключилось на отдельную команду setnewip, присутствовавшую в общем help. Общая справка показывала только её имя. Вызов help setnewip снова выдавал весь каталог команд. Только непосредственный вызов без аргументов раскрыл требуемую форму.
НАЧАЛО РЕАЛЬНОГО ЛОГА · log-011
Пользовательский вывод в переданных оператором материалах: запрос синтаксиса и вызов с адресом .5. Источник (редакционный архив: evidence/historical-excerpts.json).
Switch-A(4)> setnewip
Syntax: setnewip dotted_ip_addr
Switch-A(4)> setnewip 192.168.0.5
02:60:48:a8:00:05 doing: ifconfig eth0 lladdr 02:60:48:a8:00:05
doing: ifconfig eth0 192.168.0.5
Switch-A(4)>
КОНЕЦ РЕАЛЬНОГО ЛОГА · log-011
Теперь синтаксис имеет прямое подтверждение устройства: setnewip dotted_ip_addr. В переданном оператором опыте был указан адрес 192.168.0.5. Консоль вывела два действия: ifconfig eth0 lladdr с MAC 02:60:48:a8:00:05 и затем ifconfig eth0 с новым IPv4-адресом.
Это важное отличие от простого вызова ifconfig в предыдущем фрагменте. OEM-команда явно сообщает ещё и операцию с link-layer address. При этом в нашем материале нет отдельной проверки MAC после её выполнения: вывод doing сам по себе не равен независимому чтению результата. Корректная формулировка — «команда сообщила о назначении такого MAC», а не «измеренный MAC после изменения равен этому значению».
Последние три байта выведенного MAC совпадают с шестнадцатеричным представлением последних трёх октетов указанного IP: a8:00:05 и 168.0.5. Это арифметическое совпадение видно в одном примере. Из него нельзя выводить универсальный алгоритм генерации MAC для всех адресов, сборок или моделей. Также здесь не проверялись коллизии, правила уникальности и сохранение link-layer address после перезапуска.
В записи опыта есть разрыв. Следующий сохранённый операторский снимок показывает адрес 192.168.0.120, хотя в предыдущем фрагменте отправлено 192.168.0.5. Полной последовательности промежуточных действий нет. Поэтому следующий блок описывает позднее состояние устройства и не является доказательством, что вызов с .5 автоматически преобразует адрес в .120.
НАЧАЛО РЕАЛЬНОГО ЛОГА · log-012
Более поздний пользовательский вывод в переданных оператором материалах; переход от вызова с .5 к адресу .120 полностью не записан. Источник (редакционный архив: evidence/historical-excerpts.json).
Switch-A(4)> ifconfig -a
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33224
inet 127.0.0.1 netmask 0xff000000
eth0: flags=843<UP,BROADCAST,RUNNING,SIMPLEX> mtu 1500
inet 192.168.0.120 netmask 0xffffff00 broadcast 192.168.0.255
Switch-A(4)> showif
addr=c0a80078 mask=ffffff00 broadcast=c0a800ff
192.168.0.120 255.255.255.0 192.168.0.255
My address is class C
service processor address 192.168.0.253
Switch-A(4)> route -n show
Routing tables
Internet:
Destination Gateway Flags
127.0.0.1 127.0.0.1 UH
192.168.0.0 link#1 U
Switch-A(4)>
КОНЕЦ РЕАЛЬНОГО ЛОГА · log-012
В этом позднем состоянии ifconfig -a и showif согласуются: eth0 имеет 192.168.0.120/24 с broadcast 192.168.0.255. У service processor указан 192.168.0.253. В таблице маршрутов остались loopback и непосредственно подключённая сеть 192.168.0.0. Прежняя сеть 172.16.0.0 в этой таблице больше не отображается.
Уже при подготовке статьи мы повторили те же команды чтения через MCP. Это независимая по времени проверка позднего состояния, выполненная без повторной отправки команд смены IP.
НАЧАЛО РЕАЛЬНОГО ЛОГА · log-013
Прямое чтение через MCP 02.11.2026; команда ifconfig -a; события 4943–4959. Источник (редакционный архив: evidence/commands/ifconfig-a.txt).
ifconfig -a
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33224
inet 127.0.0.1 netmask 0xff000000
eth0: flags=843<UP,BROADCAST,RUNNING,SIMPLEX> mtu 1500
inet 192.168.0.120 netmask 0xffffff00 broadcast 192.168.0.255
Switch-A(4)>
КОНЕЦ РЕАЛЬНОГО ЛОГА · log-013
НАЧАЛО РЕАЛЬНОГО ЛОГА · log-014
Прямое чтение через MCP 02.11.2026; команда showif; события 4930–4942. Источник (редакционный архив: evidence/commands/showif.txt).
showif
addr=c0a80078 mask=ffffff00 broadcast=c0a800ff
192.168.0.120 255.255.255.0 192.168.0.255
My address is class C
service processor address 192.168.0.253
Switch-A(4)>
КОНЕЦ РЕАЛЬНОГО ЛОГА · log-014
НАЧАЛО РЕАЛЬНОГО ЛОГА · log-015
Прямое чтение через MCP 02.11.2026; команда route -n show; события 4960–4973. Источник (редакционный архив: evidence/commands/route-n-show.txt).
route -n show
Routing tables
Internet:
Destination Gateway Flags
127.0.0.1 127.0.0.1 UH
192.168.0.0 link#1 U
Switch-A(4)>
КОНЕЦ РЕАЛЬНОГО ЛОГА · log-015
Повторное чтение воспроизводит поздний снимок. Его ценность в том, что это не только пересказ оператора: адресация по-прежнему видна через доступную консоль. Но и эта проверка не закрывает исторический разрыв между .5 и .120. Одинаковые конечные значения в двух снимках не восстанавливают пропущенные команды.
Сравнение исходного и позднего состояний выглядит так:
| Поле | Исходный снимок | Поздний снимок, повторённый через MCP |
|---|---|---|
| eth0 IPv4 | 172.16.255.120 | 192.168.0.120 |
| Маска | 255.255.0.0 | 255.255.255.0 |
| Broadcast | 172.16.255.255 | 192.168.0.255 |
| Service processor | 172.16.255.252 | 192.168.0.253 |
| Непосредственно подключённая сеть | 172.16.0.0 | 192.168.0.0 |
| Default route в показанной таблице | отсутствует | отсутствует |
| Loopback | 127.0.0.1 | 127.0.0.1 |
Адреса из таблицы — выбранные для опыта частные адреса. Они не объявляются заводскими значениями EMC. Идентификатор service processor — диагностическое поле этой системы; точная команда его отдельного назначения и правило выбора последнего октета в опыте не установлены. В частности, нельзя предлагать .253 как универсальную обязательную настройку всех таких коммутаторов.
Команда route -n show отображает текущую таблицу, а не полный архив сетевой конфигурации. Отсутствие 172.16.0.0 подтверждает результат для этого снимка таблицы. Оно не доказывает отсутствие старых IP в журналах, U-Boot environment, резервных областях или сохранённой конфигурации. Этим различием объясняется, почему смену адреса нельзя называть полной очисткой данных устройства.
Для практической работы из опыта получаются два разных вида команд. Первый — команды просмотра, которые уже многократно отработали на этом экземпляре. Их можно сохранить в отдельной памятке и выполнять по одной, проверяя возвращение приглашения.
Памятка команд просмотра — не транскрипт.
ifconfig -a
showif
route -n show
env show inventory
Второй — раскрытый устройством формат команды изменения адреса:
Шаблон синтаксиса — не выполненная команда.
setnewip <IPv4-адрес>
Предыдущий блок — шаблон синтаксиса, не лог выполненной команды. Угловые скобки обозначают параметр. Этот шаблон не содержит способа изменения маски, broadcast или service processor и не является полным рецептом постоянной перенастройки устройства. В имеющемся опыте нельзя честно заполнить эти пробелы автоматически.
Практический критерий успеха следует формулировать до изменения: нужный адрес должен появиться в ifconfig -a, собственные сетевые сведения showif должны с ним согласоваться, таблица маршрутов должна соответствовать новой подсети, а VPD — сохранять идентификацию оборудования. Отсутствие сообщения об ошибке при изменении — только промежуточный факт. В нашем опыте именно последующее чтение обнаружило, что первая попытка задачу не решила.
Отдельная проверка сохранения настроек потребовала бы контролируемого перезапуска и повторного снятия тех же данных. Здесь такой проверки не было. Не было и отдельного подтверждения сетевой доступности по новому IP с внешнего компьютера: управление и чтение продолжались по последовательной консоли. Поэтому статья подтверждает видимое состояние ОС, а не доступность SSH, Telnet, HTTP или иного сервиса через Ethernet.
Этот случай полезен прежде всего как пример исследования редкой OEM-реализации. Общий help оказался неполным, специализированная команда раскрыла дополнительное действие с MAC, а похожая на обычную утилита дала неожиданный результат. Сохранённые команды и ответы позволяют следующему исследователю продолжить проверку с конкретного состояния и конкретного вопроса, не превращая предположения в «заводскую инструкцию».
Дополнение последующего исследования. В четвёртой статье через norf SHOWENV прочитано отдельное окружение: ipaddr=192.168.10.105 и serverip=192.168.10.10 при прежнем рабочем адресе 192.168.0.120. Там же сохранились макросы с адресами 172.16.* и 172.17.*. Это подтверждает наличие дополнительных сетевых значений, но не устанавливает их происхождение или процедуру очистки.
К серии и источникам · Исторические фрагменты (редакционный архив: evidence/historical-excerpts.json) · Журналы и диагностика
Who this is for
Для владельцев и инженеров, исследующих именно EMC OEM SwitchOS 1.395 на SX6018 с разрешённым консольным доступом.
When to use this
Для сопоставления своего устройства с указанной сборкой и сохранения проверяемого диагностического снимка.
When not to use this
Не переносите команды на MLNX-OS или другую сборку без отдельной проверки. Материал не заменяет процедуру sanitization и не подтверждает готовность устройства к передаче другому владельцу.
Workflow
Сопоставьте info и версии; прочитайте относящийся к задаче разбор выше; отправляйте команды по одной, дожидаясь приглашения. Отделяйте просмотр от изменения. При неожиданном ответе остановитесь и сохраните вывод.
Verification checklist
- Версии и среда совпадают с областью применимости.
- Источник, дата и полный ответ сохранены.
- Объявленная команда не выдана за выполненную.
- Пустой ответ или нулевой счётчик не заменяет независимую проверку результата.
Common mistakes
Считать обычный help полным описанием реализации; запускать команды записи из справочника; переносить поведение другой ОС; выдавать очистку буфера или смену IP за уничтожение данных.
CliDeck workflow fit
Сохранённый консольный транскрипт полезен как основание для отдельного runbook с областью применимости, ожидаемым ответом и условиями остановки. Сам факт получения лога не доказывает успех операций, которые в нём не зафиксированы.
FAQ
Проверены ли все команды?
Нет. В тексте различаются реальные ответы, встроенная справка и памятки.
Подтверждена ли полная очистка устройства?
Нет. Постоянная память, сохранение после перезагрузки и полный охват данных не подтверждены.