Hi Brian,

I think being able to show the MAC address for each interface would be EXTREMELY helpful, as would (which I didn't mention before) showing the network driver name (ie: "ASIX USB Ehternet Adapter" or "r8169 Gigabit Ethernet driver", etc). This would help one to find out (without dropping to the shell or messing with network cables) which NIC actually got mapped to which device.

I added an enhancement request to the tracker:
http://tracker.clearfoundation.com/view.php?id=1142

BTW - one question - I haven't looked at this much in COS 6.4, but do we still have to do the EXTRALANS= thing that was required in COS 5.2 to have COS route between LANS? (at the time it was in /etc/system/network, though looks like now its /etc/clearos/network.conf). This would also be nice if web admin would ask about and configure for you.

Yes, that command line parameter is still around. And yes, adding "static route manager" is on the todo list too!

Robert,

Agree with your comment on trunking... My point was that this same term is used to mean DIFFERENT things, depending on who is using it and where.

In the Cisco terminology (from the IOS perspective) when you configure "switchport mode trunk" if it carries more than one VLAN (otherwise "switchport mode access"). So in their case a "trunk" can be done over a SINGLE link.

Other terminologies of a trunk vary.

Great! Thanks Peter. I'll try it out this afternoon.

In fact, I just completed the install of COS 6.4 on my new box for home (a tiny FoxConn Atom 2700) after struggling to build and get my USB 3.0 Ethernet adapter to work without errors (fine now it seems).

So next up was configuring VLANs for my LAN. So perfect timing...

A few comments I meant to make earlier from your prior reply:

* Red Hat technically supports both the vlanY and ethX.Y syntaxes, though I believe the GUIs do default to ethX.Y. I never liked the other syntax, its just confusing, and frankly is a mess on other devices (ie: things like DD-WRT's use of VLANs).

* The Enable/Disable button for interfaces - great. Would love to see that. Was something I always felt was missing...

* I think being able to show the MAC address for each interface would be EXTREMELY helpful, as would (which I didn't mention before) showing the network driver name (ie: "ASIX USB Ehternet Adapter" or "r8169 Gigabit Ethernet driver", etc). This would help one to find out (without dropping to the shell or messing with network cables) which NIC actually got mapped to which device.

So I think both of these would be very useful. It would also be useful to be able to map a certain device name (eth0, etc) to a physical device in the GUI as well (ie: in case the hardware autoconfig got the order "wrong" (from the perspective of the one viewing)), but frankly this is no big deal if its a lot of work. Just being able to see in the GUI what is mapped where would be VERY useful.


BTW - one question - I haven't looked at this much in COS 6.4, but do we still have to do the EXTRALANS= thing that was required in COS 5.2 to have COS route between LANS? (at the time it was in /etc/system/network, though looks like now its /etc/clearos/network.conf). This would also be nice if web admin would ask about and configure for you.

Thanks! Will grab the VLAN app now and see how things go. Appreciate it!

Hi Brian and Robert,

VLAN support was added to the app-network app sitting in the "clearos-test" repository. Here's the forum thread.

Wow -- thanks for the great feedback :-)

It sounds like the configuration of the "parent" device should be left up to the end user. That makes life easier from a development point of view since no extra logic is required.

Q: I'm assuming that VLAN interfaces can have different roles. For example, eth1.1 could be a LAN and eth1.2 could be a HotLAN. Is this "best practice"? Any gotchas?

A: Absolutely. I know of NO limitations with doing this... Personally I WOULD say that this is a best practice.

Good to know. I'll make sure the "Role" (LAN, HotLAN, External) for a VLAN is a configurable option.

Continue to use the ethX.Y syntax. See no need to support the other method at all

Yup. We tend to follow the "Red Hat way" whenever possible.

Allow ability to bring down/up all interfaces (including VLANs) independently

I wonder why we don't have a disable/enable button for all the network interfaces. For DHCP and PPPoE connections, such a button needs to be Ajax/javascripted since the action can take a long time (and a very long time on failures. No matter, I'll look into it.

Consider allowing one to view the MAC address for each physical interface (probably not useful for vlans unless you can change them with MACADDRESS=)

The MACADDR parameter works with VLAN interfaces (at least by all appearances in the "ip addr" output). Is this worth exposing in the VLAN configuration interface?

The add/edit/delete VLAN implementation (static IP only) is all done and checked into SVN. It's at the "dot the i's and cross the t's" stage of filling in the above details. Almost there.

OK. I opened up 802.1Q-2011 and see that I DID remember wrong. The default VIS is 1. Here is table 9-2:

The VID is encoded in a 12-bit field. A VLAN-aware Bridge may not support the full range of VID values
but shall support the use of all VID values in the range 0 through a maximum N, less than or equal to 4094
and specified for that implementation. Table 9-2 identifies VID values that have specific meanings or uses.

NOTE—There is a distinction between the range of VIDs that an implementation can support and the maximum number
of active VIDs supported at any one time. An implementation supports only 16 active VIDs, for example, may use VIDs
chosen from anywhere in the identifier space, or from a limited range. The latter can result in difficulties where different Bridges in the same network support different maximums. It is recommended that new implementations of this standard
support the full range of VIDs, even if the number of active VIDs is limited.

Table 9-2—Reserved VID values

0 The null VID. Indicates that the tag header contains only priority information; no
VID is present in the frame. This VID value shall not be configured as a PVID or
a member of a VID Set, or configured in any Filtering Database entry, or used in
any Management operation.

1 The default PVID value used for classifying frames on ingress through a Bridge
Port. The PVID value of a Port can be changed by management.

2 The default SR_PVID value used for SRP (35.2.1.4(i)) Stream related traffic. The
SR_PVID value of a Port can be changed by management.

FFF Reserved for implementation use. This VID value shall not be configured as a
PVID or a member of a VID Set, or transmitted in a tag header. This VID value
may be used to indicate a wildcard match for the VID in management operations
or Filtering Database entries.

Some switches are limited to untagged == VID of 1. My HP switches allows me to map any VID to untagged on any port. Thus on ports 1-5 I may map untagged to VID of 8 and ports 6-8 to VID of 10 and ports 9-12 might be tagged support of VIDs 11, 12, &125. You can also mixed untagged and tagged on a single port, but some devices that do not support VLANs crash when they see ethframes with VLAN tags, so use this option carefully. So better NOT provide addressing on the non-VLAN ifcfg config, keep addressing on the VLAN ifcfg configs.

Trunking is defined where you connect switches, bridging multiple VLANs over the link. Some switches allow you to 'load balance' a number of ports for trunking purposes (same VIDs over more than one link between switches). You get what you are willing to pay for. Again, if 100Mb is good enough for you, look into the HP Procurve 2524. VT-100 telnet-style configuration menus. SSH available. (disclaimer, the previous CTO of their switch division is a friend; he stepped aside so he could get his EE PhD)

Multiple VLANs on a port is not necessarily trunking. It MAY be that you just need to do this for connectivity reasons to devices on different VLANs that happen to be connected to the same dumb switch that properly passes VLAN tags. Or it may be to connect your ClearOS server to all the VLANs it needs to be on for more efficient connection to the different VLANs. :P

Oh, one last suggestion...

Allow turning on Jumbo frames, and specifying the value (and perhaps testing it, some NIC drivers on Linux might reject certain frame sizes - ie: older Realtec ones if over 7200 for instance). So allow the user to set, use ifconfig to specify the mtu to that size, check the return (accepted or rejected) and if accepted, update ifcfg-ethX.

That would be very useful as well. :-)

Other good eBay picks are the Dell PowerConnect switches. I picked up a couple of 3448P (48 port 10/100 with PoE, 4 port GB) for under $100 (including shipping) a while back. Excellent switches!

BTW - regarding different roles on VLANs. Absolutely certain VLANs have been used by different vendors for things (such as you mention with Cisco), but they can be changed on the devices, and even can be automatically changed on bunches of devices.

From a ClearOS perspective, that no special checks need to be done with this. It needs flexibly to allow using any VLAN for any purpose and leave it up to the admin to determine how to configure (just like with managed switches).

Oh and BTW its not so much the OS that specifies a default VLAN (typically this is 1 though by default, not 0), but just industry convention that an untagged VLAN is "typically" seen to be on VLAN 1. Again, this can be changed by changing the PVID on the switch. Also MOST NIC cards (even those for laptops and home PCs) have drivers that support VLANs nowadays (though sometimes you need to download a different one). Intel ones specifically do (and are very good). So you can even VLAN your laptop (mine is since I run some test apps under VMware that I want on different VLANs). I think the Intel utility shows an untagged VLAN as having ID "0" (mine does), but in reality I don't think this is really showing the tag (as its untagged) - I think they got lazy and needed to put something in the field and chose 0 to represent untagged. So my "untagged" VLAN on my laptop with the Intel adapter shows ID 0, but REALLY it is seen as being on VLAN 1 since that's the PVID on the switch port. (showing a tag value for an interface that is "untagged" is just silly - they should fix this).

Peter,

To directly answer your questions (and note that while I don't consider myself an "expert" on this, I have done a LOT with VLANs under Linux):

Q: It's not clear in the Red Hat documentation if the "parent" interface should remain unconfigured (up, but no IP configured). Even if it is possible to configure an IP on the "parent" interface, it doesn't seem like it would be "best practice".

A: Both are "valid" configuration. On the "base" device (ie: eth2), you can specify to either give it an IP address or not. If you give it an IP, then traffic out this device will take on the PVID of the port its plugged into. If you don't, then no IP traffic can go over this interface (ie: eth2) (but still could over the PHYSICAL interface if something like eth2.1, etc are configured)

So for instance, if I have eth2 (in this case my LAN "trunk") configured as follows in /etc/sysconfig/network-scripts/ifcfg-eth2:

DEVICE=eth2

TYPE="Ethernet"

ONBOOT="yes"

USERCTL="no"

HWADDR="6c:f0:49:d1:e2:44"

BOOTPROTO="none"

IPADDR="10.10.1.250"

NETMASK="255.255.255.0"

(note above BOOTPROTO I believe was set by ClearOS to "none", no issues but "static" is probably better, since its more descriptive - thing both are the same).

Then this tells Linux to configure eth2 to be on the DEFAULT VLAN, and here that it has a static IP address of 10.10.1.250. Thus, this is an "untagged" interface. If the switchport this is plugged into has PVID set to 30 for instance, then this means that all traffic coming out of this interface (eth2 itself, not necessarily the physical port, see below) will be tagged in the switch on VLAN 30. So it depends on the PVID for that port in the switch. If its just plugged into a dumb switch or PC without VLANs, then the traffic will be untagged.

So at home personally I use the above syntax, and thus have eth2 on the "default" VLAN (ie: VLAN the PVID for the port plugged into is set). If I instead, did not give it an IP address, then I'd have to specify each VLAN. This (not providing an IP on the default device) is probably a "more correct" approach if you're using VLANs - as changing the PVID on the switch port could mess things up, especially if you are using other VLANs (imagine if PVID was 1, thus eth2 would be on VLAN 1. Let's assume I also have eth2.2 (vlan 2), eth2.3 (vlan 3), etc. Now I mistakenly change PVID to 2, oops! eth2 and eth2.2 are now on the same subnet)... So I probably should stop doing that (note that the above for eth2 is as ClearOS configured it, but I still rely on this)... But it IS valid.

So my other VLANs I have configured like (not that here I only show one, the rest are similar), eth2.2 is shown (in ifcfg-eth2.2):

DEVICE=eth2.2

TYPE="Ethernet"

ONBOOT="yes"

VLAN="yes"

USERCTL="no"

BOOTPROTO="static"

IPADDR="10.10.2.250"

NETMASK="255.255.255.0"

Note the VLAN="yes".

So just the name itself tells Linux to tag anything out of eth2.2 with VLAN ID 2.

NOTE: There is another syntax you'll find commonly used. In this one, the VLANs are specified as vlanX, where X is the VLAN ID. When configuring this way you'll NEED to specify the tag SPECIFICALLY in the ifcfg-vlanX file, and tell it to change the syntax format. I don't like this syntax as this means I can't have "vlan2" say on two different physical interfaces. the "ethX.Y" format I like much better - it tells me specifically which physical interface (ethX) AND which vlan tag Y). So I CAN have an eth0.2 and eth1.2 for instance (represent different networks of course, but both with VLAN ID 2).

-----------------

Q: I'm assuming that VLAN interfaces can have different roles. For example, eth1.1 could be a LAN and eth1.2 could be a HotLAN. Is this "best practice"? Any gotchas?

A: Absolutely. I know of NO limitations with doing this... Personally I WOULD say that this is a best practice.

And there shouldn't be (so long as the switch the port is plugged into supports VLANs and is configured correctly). Only issue I could foresee might be due to the MAC address being the same for all interfaces on the physical device (though I think you can override it with MACADDRESS= if your NIC driver supports it - not sure if this works on the VLAN devices (ie: ethX.Y) as I've never tried). But that said, I've never seen an issue related to the MAC either...

In fact... When I first installed Clear OS a while back I actually had a SINGLE physical interface in the box (it was a small book sized Atom box). I plugged my cable modem into my managed switch, put it on a NEW VLAN (99 here, and set PVID=99, only VLAN port was in was 99, port set to untagged), and then plugged the ClearOS box into a switchport (PVID=1, VLANs = 1, 2, 10, 99, port set to tagged (untagged would have worked if I wanted to use eth0)). Configured eth0.1, eth0.2, and eth0.10 as LAN and eth0.99 as "External".

This worked fine. WAN traffic from the cable modem was entirely isolated to VLAN 99 (eth0.99 on ClearOS) which no one else on the network could get to (NO other ports had access to 99 other than cable modem and ClearOS). And I still had 3 isolated VLANs/subnets that had to go through ClearOS to route traffic between (as I intended).

The ONLY limitations with the above setup was that if I wanted to remotely manage the switch this was all plugged into, I had better be VERY careful not to mess things up or else I could totally disconnect myself and everything from the Internet... :-) Of course it also means slightly less traffic max into Clear since all those VLANs are sharing the same physical interface and switch port (didn't matter on a GB port though for my purposes).



Peter - I'd love to see what you're doing with the VLAN app for ClearOS. Looking forward to this one! Here's a few of my recommendations:

[ul]