I was also bitten with this in my Cos 7.2 install.
When I added the vlan to my wan connection (i'm connected directly to the router of my wisp provider and have to use their vlan) I was not able to choose "null" on the base interface through the gui. I had to manually edit files in sysconfig/network-scripts.
I've done this manually since my connection became hard-wired (CC4? days)- they have a distribution tower on my property.
The symptom was I was able to access the internet through the firewall, but any incoming web server requests were ignored - yes port 80 was open.
I finally found network.conf hiding in etc/clearos/ and removed the base interface leaving only the tagged one in my EXTIF, and things returned to normal.
Well at least as normal as things get around here -
Cheers
Paul

This is the configuration that in most cases is the most flexible. Also means that you have one place (ClearOS) to managed all your network settings. Is especially useful if you're using ClearOS for content filtering, as you can better enforce it if it is also serving as the gateway.

Philippe Eveleigh wrote:

I currently have the cable modem setup in bridged mode - so TWC actually sees the MAC on my switch when reserving the IP - it totally passes through.

Interesting configuration ... Is there other advantages than being able to swap modems without the ISP being unaware of you doing so in this configuration?

I've got this setup .. mainly because the modem router (Virginmedia) continually reset itself to factory default losing my WiFi configuration, port forwardings etc. and I got fed up with continually reinstating them! So I put the modem in bridge mode and changed the COS server from a standalone to a gateway (adding a second NIC in the process).

Philippe Eveleigh wrote:

Interesting configuration ... Is there other advantages than being able to swap modems without the ISP being unaware of you doing so in this configuration?

Actually I believe this part of the configuration (cable modem in bridged mode) is very common. This is done to allow the device behind the cable modem to fully act as the router - basically just uses the cable modem to be a "dumb pipe" to the Internet. No NATing on the cable modem, etc. The ISP is aware as they'll actually see my actual MAC. But means I don't have to worry about port configuration on the cable modem, etc.

My particular modem allows bridged mode (which I'm using), NAT mode (cable modem is a NAT router - not something you typically want to do if you're using another NAT router behind - double NATing is a bad thing in most cases), and standard router mode (non-NAT'd).

The last mode is something I have considered, here the cable modem would see the "private" LAN and the Internet. The "private" LAN would be shared with the ClearOS (in this case) box. Routing rules could be put in the cable modem to determine what traffic passes, but it wouldn't technically be NATed. I haven't tried this (other than mistakenly having it active when I was trying to get the cable modem in bridged mode - and yes it worked). There are some advantages here (such as if you had 2 separate Internet static IPs and wished to have two different ClearOS boxes behind the same cable modem service those two independently - this would be the best way to do this - bridged I don't think could work here (no routing in a true bridge, L2 vs L3).

But bridged mode is the best in most cases.

]It seems to me that the pppoe connection for Linux is tied to a different type of network interface ? I can not see how you could reconcile ethx and pppoe interfaces to work on the same adapter for VLAN purposes?

I'd have to look at the configuration created for the pppoe interface (probably in /etc/sysconfig/network-scripts if I remember correctly), but not sure why a VLAN interface would be seen differently from a standard one with regards to PPPoE riding over it.

Years back I did have DSL (as a secondary connection to my cable) and did use ClearOS 5.2 as the router for both (didn't use MultiWAN app, wasn't available, just configured two External interfaces on COS, one to DSL modem, one to cable modem). But at the time I had the DSL modem do the PPPoE negotiation even though it was non-NATed (bridged mode, though the DSL modem referred to it as something else I think). So ClearOS did not see a pppoe interface, just eth1 (at the time had 3 physical NICs in the box, eth0 for cable modem, eth1 for DSL modem, and eth2 for the LAN, also subnetted).

But I wouldn't see why this wouldn't work with the pppoe interface on ClearOS, at least not from a Linux perspective. Not sure if the IP Settings app on ClearOS would allow this.

I really like the fact that you seem to have found a product that extends the VLAN architecture to the SSID capabilities of the AP at an affordable price.
The UniFi access point has got my interest and have been investigation it more closely I like what I see, maybe the Networking Interface on the base models being 10/100 Ethernet Port is a little weak but the rest of the features are quite impressive.

Yep, so fond of UniFi (which I initially was exposed to when setting up a network for a few non profit centers I formerly volunteered with) that I actually wrote a ClearOS app for this, that at some point may eventually be in the marketplace. :-) Considering a separate app with integration between the UniFi portal and the ClearOS directory.

With the "base" UniFis I don't see 100Mb as a big issue for the most part as while they advertise 150Mbps 802.11N, you'd never get that in real life anyway... (to go higher than the 150 you'd need the 5 GHz band, standard UniFi WAPs only ahve the 2.4 Ghz band). The higher end UniFi models (much pricer, but still cheap when compared to the competition - ie Cisco - in the higher end space) do support GB Ethernet and much faster wireless speeds.

BTW EnGenius is another company that makes fairly low cost APs that are capable of multiple SSIDs/VLANs. Have had mixed experiences with them though generally they work well once you get them to accept the configuration (a challenge from my experience). Biggest thing UniFi has over them though is the controller, portal, and all the flexibility that brings.

As I think we're venturing far off topic here, feel free to PM me or maybe even open another topic on here.

I currently have the cable modem setup in bridged mode - so TWC actually sees the MAC on my switch when reserving the IP - it totally passes through.

Interesting configuration ... Is there other advantages than being able to swap modems without the ISP being unaware of you doing so in this configuration?

I can't see any reason why it would not work

It seems to me that the pppoe connection for Linux is tied to a different type of network interface ? I can not see how you could reconcile ethx and pppoe interfaces to work on the same adapter for VLAN purposes?

But the only think that communicates on that VLAN is my UniFi access point (which sits on 3 others as well that are actually LAN).

I really like the fact that you seem to have found a product that extends the VLAN architecture to the SSID capabilities of the AP at an affordable price.
The UniFi access point has got my interest and have been investigation it more closely I like what I see, maybe the Networking Interface on the base models being 10/100 Ethernet Port is a little weak but the rest of the features are quite impressive.

Thanks Philippe. :-)

I'd imagine the ProCurve is similar and uses similar terminology to what I have (in fact, I believe SMC actually makes many of the switches the other vendors sell). I have several of different brands (SMC, Dell 48 port PoE, small TPLink 8 port GB Layer 2 that requires a Windows app to setup (no web or command line), few NetGear PoE, etc) all from different projects (only use 2 at the house). They're pretty straightforward.

The one that is the most different are Ciscos, they have slightly different ways of supporting a default VLAN, and a few other things, but generally all can be made to work together pretty easily.

Yes my WAN connection is a cable modem. I currently have the cable modem setup in bridged mode - so TWC actually sees the MAC on my switch when reserving the IP - it totally passes through.

While i haven't tried it with DSL and PPPoE in my current setup, I can't see any reason why it would not work. To be clear, in my setup, I have the cable modem plugging into my switch, and COS plugged into another port on the same switch. The Cable Modem port has PVID set to a 900 (port based) and not allowed access to any others. The COS port has PVID set to 1 (for my Admin LAN interface), but is allowed access to 900. On COS the port assigned WAN is thus eth0.900. Everything else is LAN.

A similar setup should work fine with DSL. The DSL modem wouldn't know anything about things being VLANed (it would still be using things untagged, which the switch itself would map to VLAN 900). And there are only two devices on VLAN 900 - the modem itself and the COS box, so no chance of any conflict. Would imagine PPPoE would ride over this perfectly. Of course depends on settings of the DSL modem itself - but should be no difference than with a direct cable to a dedicated port in COS to the DSL modem...


Regarding HotLANs, not using these at all... Only things I have setup are eth0.900 as External (DHCP) and the rest (0, 5, 10, etc) as LAN.

I probably should setup my Guest network as a HotLan though... But the only think that communicates on that VLAN is my UniFi access point (which sits on 3 others as well that are actually LAN). The UniFi is setup such that it doesn't let that Guest WiFi network route to the others anyway, so it frankly doesn't matter, but its probably be safer if I did define that VLAN as a hotlan... Perhaps I'll do this in the future as at some point I might remap the Ethernet port in the guest room to have the default VLAN (PVID) set to the guest network, and at that point it would cause issues without setting up as a hotlan (or custom firewall rule to prevent traffic between guest and others).

Not something I really worry about with the guests that come into my home though, but interesting to try and document a secure setup.

No problem. I often get carried away in my explanations, so I'm sure I could have phrased things better. I try to be complete, but often go overboard.

I personally appreciate the verbosity of your posts. Even if I have a different make for my switch (HP Procurve ... fanless). I believe I have been able to map your concepts with my hardware. This has been quite enlightening for me, including the POE setup

MOST useful when you're chaining switches together

This is exactly what I have done with my Virtual Switch and Hardware Switches.

I have always been interested by the subject but have never had a need to implement VLAN on my COS servers since they live in a virtual environment, and making it pointless to implement with that feature (I think).
You can create as many nics and layer 2 switches as you need on a virtual platform, note: I only have used the free vswitch that comes with ESXI.

On my home ClearOS box that I'm using as my Internet gateway (and lots of other things), I'm using a very tiny Atom based box that only has one physical NIC in it.

I am assuming that your WAN is on a cable connection, I do not think you could implement a gateway server with only one nic with PPPOe connections. Your setup has prompted a question in my mind: about the HOT LAN limit of one see: IP Settings, by curiosity have you configured more than one Hot LAN?

No problem. I often get carried away in my explanations, so I'm sure I could have phrased things better. :-) I try to be complete, but often go overboard.

No, you're definitely not REQUIRED to configure the port on the switch that you plug COS into as a Trunk, even if you use VLANs on that port. An 802.1q Trunk (ie: VLAN trunk) basically just means that on that port you're telling the switch to allow ALL VLANs in and out, basically with no restrictions. 802.1q trunks are MOST useful when you're chaining switches together (as you don't have to reconfigure all the ports every time you add a new VLAN to the network - though you still have to configure the VLANs on each switch in most cases (yes there are methods to let switches communicate this info to other switches - not getting into that here)).

So lets say that you have eth0 on your COS box and wish to use this as your LAN interface and plug this into your Layer 2 (or 3) switch... And let's say that you want to have that port on 3 different VLANs: VLAN 1 (eth0.1), VLAN 5 (eth0.5) and VLAN 10 (eth0.10).

If you define that port on the switch as an 802.1Q trunk, that means you do not need to configure at all what VLANs it has access to - it has access to ALL (whether or not the device is using them). You still specify the PVID, which is the "default" VLAN though...this way packets without tags send out of this port would then be tagged with the VLAN specified by PVID (ie: this will be the VLAN that the "eth0" device would technically be on). But with an 802.1q trunk, you do not specifically even need to tell it what other VLANs the device attached to the port has access to...

Alternatively, you can configure the port as a "hybrid" port (using terminology on my SMC switch, this would be an "access" port on a Cisco ("switchport mode access" in IOS)). If you do this, then you MUST specify which VLANs that port has access to, and ONLY these VLANs will be allowed on this port... You still specify the PVID for the default VLAN.

BTW - if you don't want to allow the default device (ie: eth0) to be able to access anything, just set PVID equal to a VLAN that is not used (in most switches you still have to define it). I usually just create a high numbered VLAN (4095) and use this.

Then on ClearOS you just configure a VLAN interface in the "IP Settings" app, and tell it the VLAN ID and which physical interface it is on. So if you tell it the interface is "eth0" and VLAN is 5, it will create eth0.5. In the event that the switchport eth0 is plugged into does not allow VLAN 5, then the interface probably will not start at all.

On my home ClearOS box that I'm using as my Internet gateway (and lots of other things), I'm using a very tiny Atom based box that only has one physical NIC in it. In the past I tried using a USB 3.0 GB Ethernet adapter to add a second, but had issues with ClearOS wiping out the driver (had to recompile the kernel to activate it) every time it installed an update (and yes I know there is a workaround for this) and eventually just decided not to use it.

So I'm using the SINGLE NIC to handle BOTH my WAN connection and all of my LAN VLANs (I have I believe 7 VLANs in actual use - Admin, Office, Media, Voice, Lab, Guest, and iSCSI). How I do this is that I plug my cable modem into my backbone switch (the SMC), and put its port in ONLY one VLAN (let's call it VLAN 99) as a hybrid port.

The ONLY other port that is in VLAN 99 is the one the ClearOS box plugs into... (well technically my trunk port between this switch and my POE switch allows VLAN 99 to traverse, but nothing uses it and the POE switch doesn't have VLAN 99 configured anyway, so it will ignore anything tagged with 99 as it has no destination to forward it to)...

So on the ClearOS box I could either 1) configure its port on the switch as a trunk (and thus have access to EVERY VLAN that the switch is configured for) or 2) individually configure EACH VLAN I want COS to access in the switch (which for me is everything other than a couple of test VLANs designed to isolate some devices that I don't want talking to anything else with no Internet access).

While option 1 would be easier and would allow the COS box to have access to any VLAN I add to the switch (assuming I created a COS interface for it), I chose option 2 here, as I personally like limited access to only what I specifically intend... Either way is valid though. (I also use the same COS as my core router to route between all the VLANs, so trunk would also be appropriate for this reason).


Hope this helps!!

After reading again your post I now see that that you where talking about subnets and not interfaces. Also I have never used COS VLAN configuration, I do use a simple/small VLAN infrastructure (VMware ESXI and layer 2 physical switches)

I had to read multiple times your post not due to lack of clarity but mostly my lack of knowledge. Again I appreciate you doing so.

I always wondered how to configure switches with a COS interfaces configured for VLAN, are we always required to enable and use Trunking on our Switch with the use of COS VLAN?

Agree totally that Layer 2 switches support VLANs...VLANs are implemented at layer 2 in the OSI model.

However Layer 2 switches can't ROUTE between subnets - they're not routers (otherwise they're working at Layer 3).

That was the point in my statement:"to support multiple different subnets on the same NIC and that the ONLY communication between them (ie: between subnets) MUST be through a router or Layer 3 switch"... If I have two different subnets with TCP/IP, I can only route between them at layer 3.

Brian, thank you for the post.

Note:

... to use VLAN is to support multiple different subnets on the same NIC and that the ONLY communication between them MUST be through a router or Layer 3 switch.

Layer 2 Switches are also a valid option for Virtual LAN'S

While I know this was a question from some time ago, in the event you still need an answer...

The physical device (eth0) will be on the VLAN specified as the "Default" VLAN (otherwise known as the PVID) that is specified by the physical port that the card is plugged into the switch. The physical device (eth0) will typically be "untagged" (ie: traffic going in and out won't have a VLAN tag), but the switch, seeing an untagged packet will then internally assign it the tag specified by the default VLAN (or PVID) for that port. The tag would then be stripped off prior to the switch sending packets back to that device. On most switches, unless you've changed the PVID setting for that switch port, this will be VLAN 1. That said, it depends on how that port is configured - if you unplug eth0 from a port that had the PVID to 1 into a port that has PVID set to something else (say 2), then that changes the VLAN that the physical port is on...

Thus, generally if I'm using VLANs on an interface, I do NOT specify an IP address for the one on the physical adapter. This way I can ensure that a switch config issue won't have the interface flipping to the wrong VLAN (at worse, a switch config issue would then only make the wrong VLANs available, so perhaps the box wouldn't get access to a VLAN - a problem easily and immediately recognizable).

When you define a sub interface (ie: eth0.1), this means that the interface is "tagged" with the VLAN id ("1" here). For "tagged" interfaces ALL packets in and out will have that VLAN tag (this is how the switch and device know what VLAN to associate the traffic with). So if I have a default interface of eth0 plugged into a port that has PVID = 1, AND also define eth0.1, then I have TWO interfaces (eth0 and eth0.1) BOTH on the SAME VLAN and by extension (assuming that the subnet mask is set the same, but even if not, there is overlap) on the SAME SUBNET. Depending on your applications this may cause issues (though there are valid reasons for doing this as well). But in MOST cases this isn't what you want to do.

Also generally EACH VLAN SHOULD BE configured for a DIFFERNT TCP/IP subnet... VLANs establish separate broadcast zones (which is one of their primary features) and thus if I have say eth0.1 and eth0.2 on subnet 192.168.0.0/24, and really expect both to receive the same traffic - broadcasts won't work between the two. In fact - no reason to subnet things if you want to do this. In most cases the reason to use VLAN is to support multiple different subnets on the same NIC and that the ONLY communication between them MUST be through a router or Layer 3 switch. (of course if you ClearOS box is serving as the router it will (based on firewall rules) copy packets between the two - but client's won't).

Also note that if you have the interfaces configured for DHCP, they'll ONLY receive a DHCP address from the VLAN that the request was sent. Generally DHCP requests are NOT routed. The exception to this is you can define a DHCP proxy that will forward the request to another subnet where the DHCP server is (proxy must have access to the subnets involved).

To make things easy to maintain, I generally use /24 subnets and just use the last octet to reference the machine, and the 3rd octet to represent the vlan/subnet. This sounds precisely like what you're trying to do. No reason you have to do this (especially if you don't use /24 sized subnets), but it makes things easy to maintain and detect errors. (I actually use the 10.x.y.z addresses for my private subnets, so use the "x" to represent the physical site (as I have VPN connectivity between them), "y" to represent the subnet in each site" and "z" to represent the device in that subnet in that site). Makes things very easy to maintain and errors in configuration pretty obvious to spot. Of course in more complex network environments with things setup historically differently, this may not be possible, but in a "Green field environment" this works very well.


For instance if you want to use the 172.18.x.y block. So do something like:

VLAN 5 172.18.5.x/24 eth0.5
VLAN 10 172.18.10.x/24 eth0.10
VLAN 20 172.18.20.x/24 eth0.20
VLAN 30 172.18.30.x/24 eth0.30

One additional thing is to consider the "Default" VLAN or PVID as mentioned above... So if this is set to "1", I'd use something like:

VLAN 1 172.18.1.x/24 eth0 (assuming PVID for switch port for eth0 is set to 1).

Also the above would be valid if eth0.1 was configured - though again, I would not suggest using eth0 (no IP) if you also configured eth0.1.

I tend often to leave all the PVIDS for ports I expect to use on the switch to 1 and assign this to an "Basic" VLAN - this has very limited access, but is just used to make it so that I can plug in a device and configure it, and probably later move it to another. In general I don't allow this VLAN (or the subnet associated with it) ANY access to the Internet and to most of the other systems on the network. Also if I am using a large switch with a lot of ports I'm not expecting to use, I'll set the PVID on them to another VLAN that is not used by anything and has NO access to anything. This way if someone comes along and plugs in a device (whether on purpose to try to gain access or accidently) they should get NO access. Of course turning off the port is an option if the switch allows it, but some don't, so I just assign PVID to a VLAN that nothing should be on, and that mitigates some of the risk (of course there are better options as well for doing this, but this is easy, and works with all VLAN capable switches).

Hope this long winded reply helps!

that is precisely my question, what is the IP address that should have the physical interface (eth0)? An IP address of the native vlan?

I don't know about VLANs but I notice you have eth0 and eth0.5 on the same subnet and I suspect that is dodgy.

Good morning, I have some basic questions, please I need help

I'm trying to set up a small network with 4 vlans, vlan 5 (172.18.5.0/24), vlan 10 (172.18.10.0/24), vlan 20 (172.18.20.0/24) and vlan 30 (172.18.30.0/24 ). but I do not know how to configure the interfaces. native vlan is 5.
What settings should I have on interfaces? because I'm currently configuring as follows and does not work.
eth0 172.18.5.2/24
eth0.5 172.18.5.3/24
eth0.10 172.18.10.2/24
eth0/20 172.18.20.2/24
eth0.30 172.18.30.2/24.

I know these are basic questions but I help a lot if you can answer them.
thanks

Good to hear!

BTW - this worked great and I have the VLAN support installed and working in the COS Pro install. Appreciate the help and quick response!

Thanks Peter. I'll try this. Greatly appreciate it! BTW - on my home system haven't seen any issues with the latest versions of the plugins, though I haven't yet had the opportunity to methodically test it. But looks good. :-)

Sorry I missed your earlier post! If you run the following command on a ClearOS Professional system, the VLAN stuff will be available:

# touch /etc/clearos/network.d/vlan

Removed stupid question... :-) Forgot that when manually adding VLANs to COS, one must add the new VLAN interfaces to LANIF= in /etc/clearos/network.conf... :-)

Guess I got so used to using the new VLAN support with this plug in COS Community, that I forgot one of the steps to manually do this. :-)

BTW - I manually configured the VLANs from the shell, so no major deal right now, but would like to see this functionality in Professional if its possible, even if it were still in beta form. :-)

Hi Peter, I just installed ClearOS Professional for a new system I'm about to deploy (currently on 30 day eval, but will be purchasing licenses early next week), and was wondering how I might be able to get this installed for Professional?

Trying the usual:

yum update
yum --enablerepo=clearos-test,clearos-updates-testing upgrade app-network

Comes back with "No Packages marked for Update".

I imagine this is probably on purpose for not allowing testing apps under Professional, but was wondering if there was any way around this?

Just curious.

Thanks, just downloaded it. Will play around with it a bit when I have some time.

Hi all. A new version was pushed to updates test a few days ago:

yum --enablerepo=clearos-test upgrade app-network

One step closer...

Thanks Nick. Didn't know that one as well, but that makes sense.

I'm having some OpenVPN (and PPTP) issues right now which I didn't have in 5.2, so I'll go back and look at this for my debugging.

Thanks Peter!

Let me know when you have another version you want me to test. Would be happy to do so.

Brian

FWIW,
Peter Baldwin wrote:

I think only the web proxy server uses EXTRALANS right now.

Also OpenVPN for the "push route" bit of clients.conf but it's a bit o/t.

Hi Brian,

Add "Connection Type" of "none" to list - ie: This would allow the ability to have an interface configured, but specify that it should NOT have an IP address. While there are probably many reasons for doing this, the most common one would be for when VLANs are configured, and one does not wish to use the base interface (ie: ethX) untagged. ie: I might wish to specify each VLAN on eth0 as tagged (ie: eth0.1, eth0.2, etc) without having eth0 itself to have an IP. This can be done by having "BOOTPROTO=none" and NOT specifying an IPADDRESS=line (and NETMASK, etc) at all.

Good idea -- added to the tracker: http://tracker.clearfoundation.com/view.php?id=1145

(also useful to set IPV6INIT=no and IPV6_AUTOCONF=no, but I don't do this, don't use IPv6 at all myself).

I'm sure that will be part of the IPv6 initiative in ClearOS 6. That reminds me, I need to go request my address block from my ISP!

Oh, and BTW - if you were to add the ability to stop/start an interface from web config (per my prior suggestions), I would recommend that if the user clicks this on the physical interface (ie: ethX) that also has VLANs configured (ethX.Y), that the app would warn the user that "Stopping or restarting a physical interface will stop or restart all VLANs configured on that interface. It you are accessing this webpage from one of those VLANs, this may disconnect you. Would you like to continue?"

Noted!

Hi Brian,

"Interface" list when adding a VLAN contains VLAN interfaces - If you're already added a VLAN interface, let's say eth0.2, then when you go back to add another VLAN interface, all the rest of the VLAN interfaces you created will appear...

Ooops. I searched all the other apps for the get_interfaces API call, but didn't check the app itself! All fixed (including filtering out VLANs when adding virtual interfaces).

Message from syslogd

That's weird.

Deleting a VLAN interface doesn't remove corresponding entry in LANIF in network.conf

I was not able to duplicate this issue. I'm guessing the broken VLAN interfaces (eth1.1.1) may have interrupted one of the API calls and it failed to do the cleanup.

Would be nice to have EXTRALANS updated when creating a VLAN. BTW - what exactly does EXTRALANS do? Modify iptables?

EXTRALANS is needed for routed networks that are not directly configured on the ClearOS system. It's not necessary for VLANs.

I think only the web proxy server uses EXTRALANS right now.

As mentioned in other thread, having a way to Enable/Disable an interface from this screen would be nice

That requires more invasive changes which need to wait for ClearOS 6.5. The VLAN support didn't touch the core network API all that much and it uses a separate add/edit GUI page. In theory, VLAN support can be released as an update to ClearOS 6.4... maybe.

Thanks Peter. I start traveling myself for work in the morning. Out the next two weeks.

BTW - let me say thanks for the work on the Network app and VLANs in paritcular. Great to have this in. While I have mentioned a few things for improvement, it is immediately useful and I used it in setting up my latest system that replaced my old COS 5.2.

Also - ignore the comment about EXTRALANS. I guess I was confused on what this did. Only discovered this after trying to start Web Proxy (after messing with EXTRALANS) and then took an hour to discover that the reason squid wouldn't start was directly related to my incorrectly understanding and using EXTRALANS. :-)

Unfortunately, I will be away until May 13 (bad timing for VLAN development). I'll circle back around when I'm back!

BTW - one additional suggestion:

Add "Connection Type" of "none" to list - ie: This would allow the ability to have an interface configured, but specify that it should NOT have an IP address. While there are probably many reasons for doing this, the most common one would be for when VLANs are configured, and one does not wish to use the base interface (ie: ethX) untagged. ie: I might wish to specify each VLAN on eth0 as tagged (ie: eth0.1, eth0.2, etc) without having eth0 itself to have an IP.

This can be done by having "BOOTPROTO=none" and NOT specifying an IPADDRESS=line (and NETMASK, etc) at all. (also useful to set IPV6INIT=no and IPV6_AUTOCONF=no, but I don't do this, don't use IPv6 at all myself).

Oh, and BTW - if you were to add the ability to stop/start an interface from web config (per my prior suggestions), I would recommend that if the user clicks this on the physical interface (ie: ethX) that also has VLANs configured (ethX.Y), that the app would warn the user that "Stopping or restarting a physical interface will stop or restart all VLANs configured on that interface. It you are accessing this webpage from one of those VLANs, this may disconnect you. Would you like to continue?"

anwoke, couple of questions:

(BTW - if you've already done all of this, please excuse the basic level of the questions)

1. Are you certain that your NIC supports VLAN tagging? While most do nowadays (including the lower end chipsets like Realtec), there are still some that have issues. In addition, the underlying drive must also support VLAN tagging.

2. Does the switch you've plugged that interface into support 802.1q tag based VLANs?

3. Do you have the switchport the interface plugged into to have that interface part of the VLANs you're trying to add? Is set correct? (ie: tagged vs untagged)?

4. What is the PVID for that port set to? (ie: default VLAN). By default its usually 1. Thus, if you haven't changed this, looks like you're trying to specify eth0 to be on the deafult VLAN (most likely 1) UNTAGGED, and eth0.1 be also on VLAN 1 as tagged (most likely though this too could be set to untagged on most switches). Thus you'd have them both on the same subnet. If you have everything else on your network correct for VLAN 1, DHCP SHOULD work, but I don't think this is the config you want.

5. Is the device you'd then trying to ping from on the same VLAN? is its port configured correctly?


From my brief test of the new plugin, it appears to work fine here (other than my caveats mentioned). And it does correctly create the ifcfg-ethX.Y files.

Peter,

So on first glance the VLAN support looks GREAT! A few little things I've found though:
[ol]