On 7/9/2010 1:32 AM, Jeff Hefner wrote: > I've still been keeping this one simmering back burner and trying to > figure the workflow for getting a system up and running with minimal > user interaction. I do realize the PXE agents don't have any concept > of tagged vlans. The thought was more along the lines of having the > ability to specify a tagged VLAN id at the boot prompt when running an > install from the console using a CD or USB drive. (ie passing > arguments to the boot loader "linux > ks=http://localwebserver/ks/server.ks ip=10.10.10.10 > netmask=255.255.255.0 gateway=10.10.10.1 dns=10.10.10.53) > My previously supplied link had a link to this article about Anaconda > being enhanced to support VLANs: > > http://rhn.redhat.com/errata/RHBA-2009-0164.html > > I've been experimenting with Spacewalk/Cobbler so this kind of extends > beyond just a basic CentOS install but whether Cobbler is part of the > equation or not, the crux of the question is to verify if Anaconda has > direct support for VLANs. I've been out of the office since I > originally posted the question so I haven't had a chance to setup some > systems to verify it for myself yet. I was hoping this was something > someone else had previous setup something like this and could verify > whether it would work. I plan on taking some time to try this out > later today. > > This is how I envision the workflow: > > a switch interface has three VLANs setup > > untagged 99 (Spacewalk/Cobbler/PXE/dhcp enabled subnet) > tagged 100 (main server subnet) > tagged 101 (backup network subnet) > > Once the machine boots up it will get an dhcp provided IP from VLAN99. > Cobbler has added an PXE entry for that machine to tell it what > kickstart file to grab which it downloads via HTTP. Once that has been > downloaded and processed the kickstart file will have the two tagged > interfaces (ie eth0.100 and eth0.101) specified and from this point > forward it continues the rest of the install process through VLAN100 > interface, eth0.100. After it finishes up it, the system reboots and > then no longer needs or uses the untagged VLAN. > > One of the issues I'm trying to work around is I'm in an environment > when I don't have end to end control over everything. In order to get > an interface changed I have to rely on a different team to make the > change so if I need an interface reconfigured from untagged to tagged > or from VLAN abc to VLAN xyz, I have to wait on someone to do it for > me. So the logic is to have everything in place that I need from start > to finish. When it's all over then the temporary untagged interface > can be removed from the switch interface without disrupting the > configured and deployed system. Hope that all makes sense. Unless you expect the switch to enforce some security restrictions for you there's really no harm in leaving an extra untagged VLAN active on the port. After you remove the IP address from the base eth? interface the host won't see it anyway (I suppose a few broadcasts would be handled by the NIC and then ignored...). If you use native vlan 1 as I suggested earlier, it would connect to ports with default settings, which might or might not be a good thing, depending on the rest of your network, but that would let a dhcp/pxe boot server span everywhere with access disappearing once you configure the host interfaces. -- Les Mikesell lesmikesell at gmail.com