Project

General

Profile

Bug #26104

Validate vlan number when configuring via the console

Added by Joshua Sirrine over 1 year ago. Updated 10 months ago.

Status:
Done
Priority:
Nice to have
Assignee:
William Grzybowski
Category:
Middleware
Target version:
Seen in:
TrueNAS - 11.0-U2.2
Severity:
New
Reason for Closing:
Reason for Blocked:
Needs QA:
No
Needs Doc:
No
Needs Merging:
No
Needs Automation:
No
Support Suite Ticket:
n/a
Hardware Configuration:
ChangeLog Required:
No

Related projects 1 project

Description

When setting up vlans from the local console via the netcli menu, the vlan options don't work quite like you'd expect.

If you choose option 3 (Configure VLAN Interface), then Option 1 (Select a parent interface) and then choose a parent interface you get the below query:

Enter an option from 1-13: 3

1) Create VLAN Interface
2) Delete VLAN Interface
Enter an option from 1-2 (enter q to quit): 1
1) cxl0
2) cxl1
3) lagg0
Select a parent interface (q to quit): 2
Enter an interface name (vlanXX) or a to abort:

If you want to use a single-digit vlan number, it seems logical that you'd use something like 'vlan04' instead of 'vlan4' since the query says "vlanXX". Unfortunately, this does not work and there are problems and the vlan configuration does not work. The input is accepted as valid, and I verified the information was stored in the configuration database, but then when you reboot for the vlan to be applied, it fails to apply. In particular, the vlan interface does not get created (a traceback on bootup occurs, but scrolls very quickly by). Simply changing the input from 'vlan04' to 'vlan4' resolved the issue.

Additionally, the menu options could probably be simplified. For example, I provided the below input:

Select a parent interface (q to quit): 2
Enter an interface name (vlanXX) or a to abort: vlan4
Enter a VLAN Tag or a to abort: 4

I think we should simply get rid of the vlanXX input for the interface name and simply ask for the VLAN Tag. Then take whatever number they put in, and preface it with 'vlan' to make the interface name. Someone could easily enter 'vlan4' and then for the tag input put some other arbitrary number that would add more confusion. I'll leave that to the developers to decide if this simplification is something we should do or not. Personally, I can't think of a time when we'd want to name the interface something different.

vlanX-26104-2018-06-15.png (7.97 KB) vlanX-26104-2018-06-15.png Michael Reynolds, 06/15/2018 02:14 PM
18622

Associated revisions

Revision edacf1d4 (diff)
Added by William Grzybowski over 1 year ago

fix(netcli): validate vlanX in netcli

Ticket: #26104

Revision 05550733 (diff)
Added by William Grzybowski over 1 year ago

fix(netcli): validate vlanX in netcli

Ticket: #26104

History

#1 Updated by Bartosz Prokop over 1 year ago

  • Status changed from 50 to 51

Nice description Josh - pushing to devs.

#2 Updated by Dru Lavigne over 1 year ago

  • Category set to 42
  • Status changed from 51 to Unscreened
  • Assignee changed from Bartosz Prokop to William Grzybowski

William: please load balance.

#3 Updated by William Grzybowski over 1 year ago

  • Project changed from TrueNAS to FreeNAS
  • Category changed from 42 to 2
  • Status changed from Unscreened to Screened
  • Target version set to 11.2-BETA1

#4 Updated by Dru Lavigne over 1 year ago

  • Description updated (diff)

#5 Updated by Dru Lavigne over 1 year ago

  • 1 added project (TrueNAS)

#6 Updated by William Grzybowski over 1 year ago

If we just use the tag how would we handle migrations?

Say someone used vlan111 with tag 11 by mistake and vlan111 is used in a number of places?

#7 Updated by Joshua Sirrine over 1 year ago

What I'm proposing is getting rid of the virtual interface field and having us generate it internally based on the tag. So tagged 11 traffic would be vlan11, tagged 111 traffic would make vlan111. After all, regardless of the virtual interface field, if we move everything to the standard I recommend, it's all internal, right? We should expect that customers are going to go to the CLI and try to do manual networking.

Am I missing something here? I am a bit green with regards to vlan stuff, so I may be missing something critical for why this idea is stupid.

#8 Updated by William Grzybowski over 1 year ago

I am not asking how it should be implemented, thats pretty clear. I am asking how we handle existing installs which vlan interface name does not match vlang tag.

e.g. vlan35 tag 67

#9 Updated by Joshua Sirrine over 1 year ago

Oh, I gotcha. Why not simply convert the vlan interfaces themselves along with any other entries in the config file to point to the correct "new" name?

#10 Updated by William Grzybowski over 1 year ago

Interface names can be used in a number of places, in bind for a few services, reporting graphs, etc.

Not sure its worth the risk

#11 Updated by iXsystems Bot over 1 year ago

Commit: 055507330ef2791f2172990b7107a5d2867d73fc
https://github.com/freenas/freenas/commit/055507330ef2791f2172990b7107a5d2867d73fc
Author: William Grzybowski <>
Date: 2018-01-09 (Tue, 09 Jan 2018)

Log Message:
-----------
fix(netcli): validate vlanX in netcli

Ticket: #26104

#12 Updated by William Grzybowski over 1 year ago

  • Status changed from Screened to Ready For Release

#13 Updated by William Grzybowski over 1 year ago

#14 Updated by Dru Lavigne about 1 year ago

  • Subject changed from vlanXX input cause problems on 11.0-U2.2 to Validate vlan number when configuring via the console
  • Status changed from Ready For Release to Done
  • Needs Doc changed from Yes to No
  • Needs Merging changed from Yes to No

#15 Updated by Dru Lavigne 12 months ago

  • Status changed from Done to Ready for Testing

#16 Updated by William Grzybowski 11 months ago

  • Category changed from GUI (new) to Middleware

#17 Updated by Michael Reynolds 10 months ago

18622

The fix for this was to change vlanXX to vlanX to remove confusion.
This is done.
see vlanX-26104-2018-06-15.png

#18 Updated by Dru Lavigne 10 months ago

  • Status changed from Passed Testing to Done

Also available in: Atom PDF