Opened 7 years ago
Last modified 8 months ago
#272 new улучшение
Кнопка "Применить" на вкладке Ethernet->VLAN, Ethernet->RSTP
| Reported by: | san | Owned by: | alx |
|---|---|---|---|
| Priority: | средний | Milestone: | 2 очередь |
| Component: | web-интерфейс (sw) | Keywords: | |
| Cc: | andrei, anatoly, vlad, artem, viktam, Ivanmvtel |
Description
Предлагается вместо немедленной записи каждого изменения настроек в коммутатор, записывать все изменения только после нажатия кнопки "Применить".
За время работы аппаратуры разные пользователи жалуются на неудобство "мгновенного" применения настроек на вкладке Ethernet->VLAN. Случайно ткнув мышкой парой пикселов правее-левее можно сломать связь с блоком.
Кроме этого, "пошаговая" настройка немного сложнее, т.к. нужно соблюдать определённую последовательность действий, чтобы не потерять связь с блоком.(например при переносе порта CPU в другой VLAN нужно обязательно сначала создать новый vlan, а потом уже удалять старый) А недавно я сам столкнулся с неудобством такого подхода настраивая VLAN на блоках в кольце RSTP("промежуточные" состояния настройки сложно проанализировать, кроме того шаги вызывают кольца и перестроения дерева, и гораздо проще было бы настроить за "одно применение" чем пошагово.
p.s. Ваня сравнивает настройку VLAN на нашей аппаратуре с игрой Сапёр.
Change History (22)
follow-up: 3 comment:2 by , 7 years ago
Можно как-то его раскрыть на примерах?
Ну, скажем, есть некая топология RSTP и на одном блоке есть порт, который я хочу исключить из vlan-а. Мне нужно совершить три шага:
- в ячейке таблице поменять U на T
- поменять T на пусто
- в "untagged vids" указать другое значение
На шаге 2 у меня "всё сломалось" - образовалось неразрывное кольцо и начался шторм.
Почему? Подозреваю что это как-то связано с "несиметричностью" получившихся настроек порта, т.е. входящие пакеты проходят(попадая согласно настройке untagged vid в мой vlan) а исходящие уже не проходят(т.к. галка снята в строке vlan-а). И видимо коммутатор на той стороне не увидев исходящих от моего порта BPDU перевёл свой порт в forwarding а входящие в мой порт создали кольцо и шторм.
С другой стороны, почему я должен об этом думать?
Меня не интересует состояние"шаг 2". Моя цель - состояние "шаг 3".
comment:3 by , 7 years ago
Replying to san:
- в ячейке таблице поменять U на T
- поменять T на пусто
- в "untagged vids" указать другое значение
На шаге 2 у меня "всё сломалось" - образовалось неразрывное кольцо и начался шторм.
Во-первых, это случай неверного планирования действий? Верно? :) Если выполнять описанные действия в порядке 3-1-2, то проблемы, насколько я понимаю, не будет. Так?
Во-вторых, упростить данную операцию поможет функция "Выключить порт", соответствующий тикет уже есть: #251.
follow-up: 5 comment:4 by , 7 years ago
Во-первых, это случай неверного планирования действий? Верно? :) Если выполнять описанные действия в порядке 3-1-2, то проблемы, насколько я понимаю, не будет. Так?
отсутствие волшебной кнопки, именно и приводит к избыточной необходимости планирования
comment:5 by , 7 years ago
Replying to san:
отсутствие волшебной кнопки, именно и приводит к избыточной необходимости планирования
Я как раз боюсь, что эта "волшебная кнопка" в данном случае не помогла бы: здесь, очевидно, на момент планирования действий 1 и 2, то есть отключения передачи данных в порт, было "забыто", что еще и прием надо отключить (действие 3). Поэтому очень легко себе представляю, как после выполнения пунктов 1 и 2 нажимается кнопка "Применить", а потом: "Ах, черт возьми, что происходит? А, ну конечно, про обратное направление забыли!!!" :) Так что, как ни крути, от необходимости тщательного планирования это не избавит, и "избыточным" ты назвал его, по-моему, зря...
Вот "отключение порта" помогло бы больше - оно сразу отключает и прием, и передачу. Сложнее ошибиться...
follow-up: 7 comment:6 by , 7 years ago
В данном случае, для меня планирование шагов как-раз и было избыточным, т.к. я ориентировался на конечный результат, но согласен, что кнопка не избавит от всех возможных ошибок.
Пока писал - вспомнил ещё один Ванин аргумент(в последний раз этот вопрос снова поднял Ваня), он утверждал, что в подавляющем большинстве коммутаторов Eth разных производителей логика применения подобных настроек в веб-морде - "через кнопку Применить", и пользователи считают это неким устоявшимся, привычным вариантом, поэтому наш "оригинальный" вариант им не нравится. Не могу прокомментировать этот аргумент, т.к. я не так много разной аппаратуры настраивал, наверное надо Артёма подключить к обсуждению.
comment:7 by , 7 years ago
Replying to san:
пользователи считают это неким устоявшимся, привычным вариантом, поэтому наш "оригинальный" вариант им не нравится.
Вот это - хороший аргумент.
comment:8 by , 7 years ago
да, у большинства производителей есть кнопка применить apply. Она более привычна, чем ее отсутствие.
follow-up: 10 comment:9 by , 7 years ago
Точно. А еще есть "отмена", нажав которую станет хорошо. У нас так не прокатит.
comment:10 by , 7 years ago
Replying to andrei:
Точно. А еще есть "отмена", нажав которую станет хорошо. У нас так не прокатит.
А что она делает, и почему у нас не прокатит?
follow-up: 13 comment:12 by , 7 years ago
Я имел в виду ситуацию, когда ставишь случайно неправильную галку и доступ к блоку перестаёт быть.
comment:13 by , 7 years ago
Replying to andrei:
Я имел в виду ситуацию, когда ставишь случайно неправильную галку и доступ к блоку перестаёт быть.
Логика подсказывает, что если к блоку нет доступа, то уже никакая кнопка веб-интерфейса не поможет...
Зато именно на такой случай у нас есть отложенный рестарт, который, как мне кажется, вряд ли есть у большинства других производителей!
comment:15 by , 7 years ago
отложенный рестарт показывает что мы очень любим наших клиентов. у остальных производителей я не встречал, если при удаленном конфигурировании пропал доступ к девайсу. то сам себе злобный буратина.
comment:16 by , 6 years ago
| Cc: | added |
|---|
comment:17 by , 6 years ago
| Summary: | Кнопка "Применить" на вкладке Ethernet->VLAN → Кнопка "Применить" на вкладке Ethernet->VLAN, Ethernet->RSTP |
|---|
По просьбе Вани добавил вкладку Ethernet->RSTP в название
comment:18 by , 8 months ago
Хотелось бы вернуться к примеру, описанному в comment:2. Я никак не могу понять, каким образом при выполнении пункта 2 могло возникнуть кольцо. Выполнение пункта 2 приводит к тому, что пакеты, маркированные VLAN, из которого исключается порт, перестают передаваться в этот порт. Собственно, именно пункт 2 и решает поставленную в примере задачу - исключить порт из VLAN (пункт 3 здесь, строго говоря, лишний, это уже какая-то другая задача - перенастройка маркировки принимаемых пакетов)... Как прекращение передачи пакетов в порт может привести к образованию кольца?
Может кто-нибудь пояснить "на пальцах", что именно в данном случае произошло?
follow-up: 20 comment:19 by , 8 months ago
Может кто-нибудь пояснить "на пальцах", что именно в данном случае произошло?
Возможно 6 лет назад снятие галочки в столбце порта приводило только к запрету передачи пакетов из этого вилана в порт, а в обратную сторону из порта в Vlan пакеты по прежнему могли попадать (есть у меня смутные воспоминания, что функция этой галочки немного менялась когда-то давно).
Давай лучше другой пример - проще
Блок мониторится через VLAN1, а мне нужно замониторить блок из VLAN 777
- Нужно добавить строку VLAN 777, отметить там нужные порты
- В untagged VIDS установить для порта CPU 777
Если в алгоритме 1 и 2 поменять местами:
- В untagged VIDS установить для порта CPU 777
- Добавить строку VLAN 777, отметить там нужные порты
То после выполнения 1, пользователь потеряет связь с блоком через VLAN 1 и не сможет закончить настройку.
Этот пример довольно простой, но в любом случае гораздо удобнее, настроить сразу нужную конфигурацию и нажав кнопку применить получить именно то что хотел, чем продумывать пошаговый план анализируя как будут работать все промежуточные конфигурации.
comment:20 by , 8 months ago
Replying to san:
Возможно 6 лет назад снятие галочки в столбце порта приводило только к запрету передачи пакетов из этого вилана в порт, а в обратную сторону из порта в Vlan пакеты по прежнему могли попадать.
Воспоминание правильное. Именно так эта галочка (точнее, буква) работала 6 лет назад, и именно так она по-прежнему работает сегодня.
(есть у меня смутные воспоминания, что функция этой галочки немного менялась когда-то давно).
Думаю, что эти воспоминания ложные - в поведении этих чекбоксов ничего не менялось.
Давай лучше другой пример - проще
Хорошо. Тогда пример из comment:2 так и останется для меня загадкой...
follow-up: 22 comment:21 by , 8 months ago
Воспоминание правильное. Именно так эта галочка (точнее, буква) работала 6 лет назад, и именно так она по-прежнему работает сегодня.
Поведение галочек может и не менялось, менялась настройка поведения коммутатора, вроде "что делать с пакетами полученными из портов куда не форвардится вилан", но это не точно
comment:22 by , 8 months ago
Replying to san:
Поведение галочек может и не менялось, менялась настройка поведения коммутатора, вроде "что делать с пакетами полученными из портов куда не форвардится вилан", но это не точно
Ты наверное говоришь о настройке Ingress filtering.
Replying to san:
Согласен, такая вероятность есть. Для решения данной проблемы по предложению Виктора в нашей аппаратуре была реализована функция "Отложенный рестарт". Суть ее в следующем: перед тем как начать потенциально "опасные" изменения настроек блока оператор инициирует рестарт swd, скажем, через 5 минут. После этого приступает к изменениям настроек. Если в результате случайной ошибки с блоком пропадет связь, по истечение 5 минут будет выполнен рестарт, в результате которого блок вернется к исходной рабочей конфигурации. В случае успешного внесения изменений оператор отменяет рестарт и сохраняет конфигурацию.
Кнопка "Применить" же, на мой взгляд, в описанной ситуации не поможет: в 99% случаев оператор не заметит, что он "промахнулся", снял/поставил галочку не тому порту, пока не применит изменения и не обнаружит, что связь пропала. Простая психология: когда ты что-то делаешь, ты уверен, что это правильно. :)
Согласен. Но, с другой стороны, по логике, любые работы с введенным в эксплуатацию оборудованием требуют планирования: составляется план, в котором указывается, в какой последовательности какие действия должны производиться оператором. И потом оператор строго по этому плану производит изменения в оборудовании - вспомните, как мы перенастраивали блок в Шабурах, например... Если оператор полез изменять настройки, не спланировав должным образом свои действия - он, как говорится, "сам себе злобный Буратина". :) Безусловно, есть вариант, что план составлен, продуман, но, тем не менее, содержит ошибку - так в этом случае и кнопка "Применить" вряд ли поможет, см. выше об "отложенном рестарте"...
Вот это уже более существенный аргумент. Можно как-то его раскрыть на примерах? А то мне приходит в голову пока только ситуация, когда на одной стороне форвард (или STP) уже включили, а на другой - еще нет, но в этой ситуации, опять же, кнопка "Применить" не поможет, так как это настройки в разных блоках. Здесь, опять же, на мой взгляд, поможет только тщательное планирование...
Знаю такую игру. Повторю свое мнение: кнопка "Применить" позволит Ване подорваться не при установке чекбокса, а при нажатии кнопки "Применить". Вряд ли это ему очень сильно поможет... :)