eralde

Это не проблема, а сознательное решение. Статус работы комбинированного порта (SFP + Ethernet) отображается только на дашборде. На всех остальных страницах цвета портов соответствуют цветам портов на корпусе. Вы можете создать тему в "Развитии" с предложением сделать по-другому.

@T@rkus спасибо, воспроизвел на своем устройстве. К веб-интерфейсу это не имеет отношения, но что-то явно работает не так.

Опишите, пожалуйста, пошагово, что вы делаете. Мне пока не удается воспроизвести проблему: Screen Recording 2022-12-31 at 13.08.43.mov

В версии 4.0 Alpha 2 веб-интерфейс будет показывать корректное название проводного подключения, если еще раз поменять что-нибудь в настройках этого подключения (например, название 😁) и сохранить изменения.

Я согласен с тем, что в новой версии что-то сломано. Но чинить это нужно в системной части, а не в интерфейсе, который работает так же, как работал до этого.

Этот переключатель включает/выключает GigabitEthernet1 (или другой Vlan-интерфейс в зависимости от устройства и настроек). Можно проверить по логу: Screen Recording 2022-12-29 at 08.48.54.mov Что значит Network::Interface::Ppp: "PPPoE0": connection service standby. лучше спросить у @Le ecureuil

Вам может подойти: При такой настройке будет стандартная HTTP-авторизация (https://en.wikipedia.org/wiki/Digest_access_authentication) или вообще свободный доступ.

Сппасибо, уже понятно, что ситуация требует исправления. Мы подумаем как сделать так, чтобы не дергать лишний раз настройки на интерфейсе.

Отправка no ip global была добавлена для остановки DHCP-клиента на ge1 в сценарии, когда задан какой-то VLAN для интернета. Штош, видимо, придется еще пару условий в этом месте дописать 🤖

@Le ecureuil посмотри, пожалуйста.

@Kamil какая точно модель у вашего устройства? (это можно посмотреть, выполнив через telnet команду show version)

Коллеги сказали, что нужно проверить ещё раз в следующей версии 🤷‍♂️

@saffe статус Not connected отображается, если в ответе команды "show crypto map", в поле "ike_state", написано "UNDEFINED". В вашем случае это именно так: Это условие одинаково в коде веб-интерфейса в 3.8 и в 3.9. Поправить силами веб-интерфейса это нельзя. Передаю информацию коллегам, которые отвечают за системную часть. Доступ можно закрыть. Спасибо

Подождите ещё немного, пожалуйста

Спасибо, постараюсь сегодня посмотреть, есть ли разница в веб-интерфейсе 3.8/3.9. Если её нет -- напишу коллегам, которые занимаются прошивкой.

Предоставьте, пожалуйста, даныне для доступа к устройству, где статус отображается неверно. Здесь скрытым сообщением или в личные сообщения мне, например.

@keenet07 вы правы, вашим способом можно создать два одинаковых правила (первое и третье по счету): [ { "acl": "_WEBADMIN_Guest", "index": "87c78140366d42aa2c4261507412b607", "action": "permit", "protocol": "ip", "source": "0.0.0.0", "source-mask": "0.0.0.0", "destination": "1.2.3.4", "destination-mask": "255.255.255.255", "disable": true }, { "acl": "_WEBADMIN_Guest", "index": "af28a9fd6944a5948276e658cc4fa551", "action": "deny", "protocol": "ip", "source": "0.0.0.0", "source-mask": "0.0.0.0", "destination": "87.250.250.242", "destination-mask": "255.255.255.255", "disable": true }, { "acl": "_WEBADMIN_Guest", "index": "87c78140366d42aa2c4261507412b607", "action": "permit", "protocol": "ip", "source": "0.0.0.0", "source-mask": "0.0.0.0", "destination": "1.2.3.4", "destination-mask": "255.255.255.255", "disable": true }, { "acl": "_WEBADMIN_Guest", "auto-delete": true } ] На мой взгляд, это выглядит как ошибка. Надо будет попросить коллег, которые занимаются прошивкой, посмотреть внимательнее. Общую идею про создание "почти такого же" правила я услышал. Передам её руководству. Спасибо за обсуждение

В конфиге этот идентификатор не видно, к сожалению. Попробую на своём устройстве воспроизвести и посмотрю. Насколько я понимаю, должны удаляться оба, конечно. И включаться/выключаться тоже.

Честно говоря, я не знаю, что проверяет прошивка при создании нового правила. Но известно, что создать, например, два правила "Разрешить всё через TCP" или "Разрешить всё через UDP" нельзя. Попробовал вручную создать два правила "Разрешать любой IP-трафик до конкретного IP" -- воспроизвести ваш случай не удается. Возможно, действительно, проверка где-то не сработала. Интересно вот что: при настройке через веб-интерфейс правила, начиная с какой-то версии 2.x, идентифицируются по значению поля index, которое вычисляется по конфигурации правила. В вашем случае значение index должно быть одинаково.

Расскажите, пожалуйста, зачем это нужно? Добавить два одинаковых правила в один список правил прошивка не позволяет. В этом легко убедиться, если попробовать создать правило дважды, не меняя ничего в редакторе настроек правила. Что должно происходить при создании копии правила в том же самом списке?

Да, так и должно быть. К сожалению, пока непонятно, что приводит к этой ошибке.

startup-config, боюсь, ничем не поможет. Если у вас получается воспроизвести эту ситуацию, запишите, пожалуйста, видео со всеми манипуляциями в веб-интерфейсе.

Отдельной документации по REST API, к сожалению, нет. Но всегда можно посмотреть, как выглядит JSON при чтении нужного раздела конфигурации. Например, создадим ip http proxy через CLI: После этого читаем конфигурацию в виде JSON: Меняем upstream и порт: Перечитываем конфигурацию:

Можно сделать вот так: ip hotspot host {mac} no policy ip hotspot host {mac} deny Первая команда удаляет политику созданную вручную (если она назначена этому устройству), вторая запрещает доступ в Интернет вообще. Чтобы вернуть политику по умолчанию нужно будет выполнить ip hotspot host {mac} permit Чтобы вернуть какую-то политику доступа, созданную вручную: ip hotspot host {mac} permit ip hotspot host {mac} policy {policy}

Что-то поменяли в базовом языке (английском). При этом автоматически пропадают переводы на все остальные языки. Поправят со временем