Opened 7 months ago
Last modified 3 months ago
#690 reopened улучшение
Улучшить механику настройки строки VLAN таблицы
Reported by: | san | Owned by: | alx |
---|---|---|---|
Priority: | фигня | Milestone: | 1 очередь |
Component: | web-интерфейс (sw) | Keywords: | |
Cc: |
Description
Недавно в процессе конфигурации блоков "обнаружил" неприятный эффект в таблице VLAN в кратких настройках Ethernet. Мне необходимо в строке VLAN 1 для порта, к которому я подключен, чекбокс T изменить на U. И оказалось сделать это непросто, т.к. между T и U присутствует значение "пусто", а выбирая пусто, я отключал форвардинг пакетов к себе :-)
Конечно есть варианты как обойти эту неприятность, но мне подумалось, что может быть мы можем как-то улучшить механику этой настройки... как пока не знаю
Attachments (2)
Change History (21)
follow-up: 2 comment:1 by , 7 months ago
comment:2 by , 7 months ago
Replying to alx:
Если честно, я не понял, в чем именно заключается неприятность,
Я вдруг вспомнил некий пример, который мне кто-то сравнительно недавно приводил. Он заключался в том, что если производить изменения в "правильной" последовательности (от дальнего хоста к ближнему), то при изменении режима порта с тегированного на нетегированный связь с хостом пропадет, но она потом восстановится, когда у всех остальных хостов (более близких к оператору, с которыми связь все еще есть) будут сделаны соответствующие изменения. О подобном случае идет речь?
follow-up: 4 comment:3 by , 6 months ago
О подобном случае идет речь?
Нет, в моём случае связь вообще не появится :-)
Мне нужно настройку порта, через который я подключен, с T изменить на U, и я никак этого не могу сделать, т.к. нажимая на T я устанавливаю настройку "пусто" и трафик перестаёт ко мне форвардится в этом vlan и я теряю связь с блоком.
Верно ли я понял, что предложения по улучшению аппаратуры у тебя нет?
Я думал над тем как эти галочки сделать "безопаснее" и имхо было бы удобно работать со строками таблицы VLAN и строкой Untagged Vid как со списком окончаний платы VE, т.е. после изменения строки она становится "оранжевой", а настройки применяются только по нажатию кнопки Применить.
comment:4 by , 6 months ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
Replying to san:
Я думал над тем как эти галочки сделать "безопаснее" и имхо было бы удобно работать со строками таблицы VLAN и строкой Untagged Vid как со списком окончаний платы VE, т.е. после изменения строки она становится "оранжевой", а настройки применяются только по нажатию кнопки Применить.
Не вижу в этом улучшения в деле отпиливания ветки, на которой сидишь. Связь-то все равно пропадет, хоть не в момент изменения чекбокса, но в момент нажатия "Применить"...
Так как конкретного предложения нет (и я думаю, что быть не может в принципе), тикет закрываю.
follow-up: 6 comment:5 by , 6 months ago
Связь-то все равно пропадет, хоть не в момент изменения чекбокса, но в момент нажатия "Применить"..
Нет, же.
Проблема в том, что я не хотел записывать "пусто", это интерфейс меня "заставил". Мне нужно было записать U.
comment:6 by , 6 months ago
Replying to san:
Связь-то все равно пропадет, хоть не в момент изменения чекбокса, но в момент нажатия "Применить"..
Нет, же.
Проблема в том, что я не хотел записывать "пусто", это интерфейс меня "заставил". Мне нужно было записать U.
Что "нет"? Сеть работает с тегированными пакетами. Ты меняешь режим порта, и порт вместо тегированных начинает передавать в сеть нетегированные пакеты. Он же не сможет работать с сетью после этого...
follow-up: 8 comment:7 by , 6 months ago
Он же не сможет работать с сетью после этого...
Зависит от настроек оборудования, которое подключено к порту. В моём случае я мог работать и с тегированными и с нетегированными пакетами. А в общем случае будет ситуация из comment:2, когда потребуется настройка ближайших звеней цепи и после этого всё заработает.
Но интерфейс "заставил" меня записать пусто вместо U и дальше уже хоть что делай на ближней стороне, связь не появится.
comment:8 by , 6 months ago
Replying to san:
Он же не сможет работать с сетью после этого...
Зависит от настроек оборудования, которое подключено к порту. В моём случае я мог работать и с тегированными и с нетегированными пакетами.
Тут ты по-моему начал подгонять условия задачи под решение. :)
Я понимаю так:
- Если в сети используются тегированные пакеты, то, скорее всего, они в ней все должны быть тегированные. Соответственно, не тегированные пакеты в такой сети просто никто не будет принимать (они будут отбрасываться). Не знаю как в других системах, но в linux тегированный и нетегированный трафик попадают в два разных логических интерфейса. Теоретически их, конечно, можно объединить мостом, но это лишняя морока и непонятно, нафига это может кому-либо потребоваться. В FreeBSD по-моему так же...
- Даже если в сети используются как тегированные, так и нетегированные пакеты, то скорее всего они принадлежат разным VLAN (потому что непонятно, зачем кто-то будет настраивать сеть таким образом, чтобы одна VLAN работала и с теми, и с другими - см. выше). Таким образом, изменение режима порта приведет к тому, что передаваемые им пакеты будут попадать в другую VLAN. Мало того, что его трафик работать перестанет, так он еще и может помешать работе той VLAN, в которую эти пакеты начнут попадать...
- Третье соображение я забыл, пока писал первые два. :)
А в общем случае будет ситуация из comment:2,
??? Ты же на мой прямой вопрос в commant:2 "О подобном случае идет речь?" ответил "Нет"! Так значит все-таки речь идет именно о такой ситуации?
follow-up: 10 comment:9 by , 6 months ago
Тут ты по-моему начал подгонять условия задачи под решение. :)
Ну я ничего не подгонял, это реальный случай, просто у сети было такое промежуточное(недонастроенное) состояние когда и тегированные и нетегированные пакеты одного VLAN могли ходить.
Так значит все-таки речь идет именно о такой ситуации?
Ну в конкретно моём случае ничего на других узлах не нужно было настраивать, поэтому я и ответил нет :-), но этот случай скорее исключение.
В общем случае, да будет именно такая ситуация. Суть в том что в текущей механике настроек строки VLAN для переключения с T на U нужно обязательно записать промежуточное значение настройки "пусто" (значение которое пользователь не хотел записывать).
comment:10 by , 6 months ago
Resolution: | invalid |
---|---|
Status: | closed → reopened |
Replying to san:
Так значит все-таки речь идет именно о такой ситуации?
Ну в конкретно моём случае ничего на других узлах не нужно было настраивать, поэтому я и ответил нет :-), но этот случай скорее исключение.
Понятно. Тогда у меня самого есть предложение решения проблемы этого редкого частного случая. Я могу сделать, чтобы при клике чекбокса появлялся диалог, в котором можно выбрать нужный режим, и этот режим будет записываться при нажатии OK в этом диалоге. Но меня только сильно смущает то, что ради редкого частного случая я сделаю хуже пользователям во всех остальных случаях (будет требоваться совершить больше действий для изменения режима), особенно учитывая, что вариант с диалогом и так уже есть в полных настройках ethernet. Я еще подумаю...
comment:11 by , 6 months ago
Я тоже думал о варианте с диалогом вместо чекбокса и мне он тоже не нравится.
by , 6 months ago
comment:12 by , 6 months ago
Есть еще один вариант - сделать два отдельных чекбокса - один для включения порта в VLAN как тегированного, другого - как нетегированного. Примерно как это сделано в конфигурации платы GE-04:
Тогда любое изменение режима порта потребует один клик, и диалог не нужен. Но чекбоксов будет в два раза больше, именно от этого я и хотел уйти, когда сделал чекбоксы с тремя состояниями...
comment:13 by , 6 months ago
Есть еще один вариант - сделать два отдельных чекбокса
Тоже об этом думал, и мне вариант с двумя наборами чекбоксов нравится меньше, я даже наоборот хотел для GE-04 предложить сделать чекбоксы U/T, т.к. они удобнее и нагляднее :)
Проблемма с чекбоксами U/T в SW-01 в необходимости записывать промежуточное состояние "пусто" при переключении, в GE-04 такой проблеммы нет, т.к. настройки записываются только по команде пользователя.
Ещё у меня была мысль, переключать U/T кликом, а длинным нажатием переключать в "пусто", только не знаю насколько это интуитивно при настройке, как-то непривычно будет мне кажется.
follow-up: 15 comment:14 by , 6 months ago
Ещё с давних времён, с подачи Артёма, у меня есть мысль добавить альтернативный существующему вариант настройки VLAN таблицы. Такой вариант "Циско-стиль", в котором настраивается не галочки портов для VLAN, а наоборот, для портов указывается какие VLAN в каком виде через них передаются. Постараюсь позже описать этот вариант и его преимущества подробно.
comment:15 by , 6 months ago
Replying to san:
"Циско-стиль", в котором настраивается не галочки портов для VLAN, а наоборот, для портов указывается какие VLAN в каком виде через них передаются.
Звучит интересно...
by , 6 months ago
comment:16 by , 6 months ago
follow-up: 18 comment:17 by , 3 months ago
Появилась новая идея: чекбокты и их переключение оставить такое, как есть сейчас (U
-> T
-> пусто
), но применять новое состояние не сразу, а после некоторого таймаута (например 1 секунда) с момента последнего клика.
follow-up: 19 comment:18 by , 3 months ago
Replying to alx:
Появилась новая идея: чекбокты и их переключение оставить такое, как есть сейчас (
U
->T
->пусто
), но применять новое состояние не сразу, а после некоторого таймаута (например 1 секунда) с момента последнего клика.
Это конечно будет немного лучше чем сейчас, но из вариантов доработки существующего интерфейса мне больше понравились "трехпозиционные переключатели".
comment:19 by , 3 months ago
Replying to san:
из вариантов доработки существующего интерфейса мне больше понравились "трехпозиционные переключатели".
Жаль... Мне они не нравятся чисто эстетически...
Есть другая вариация идеи, описанной в comment:17: при клике чекбокса вместо запуска таймера показывать рядом с ним иконку "Применить" (), и применять изменение по клику по ней. Хотя это будет менее удобно, чем с таймером...
Replying to san:
Если честно, я не понял, в чем именно заключается неприятность, о которой ты говоришь. Но это, наверное, не важно, так как (см. ниже)...
Верно ли я понял, что предложения по улучшению аппаратуры у тебя нет?