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. jeff On Wed, Jul 7, 2010 at 5:11 PM, Blake Hudson <blake at ispn.net> wrote: > -------- Original Message -------- > Subject: Re: [CentOS] Kickstart from tagged VLAN? > From: Les Mikesell <lesmikesell at gmail.com> > To: CentOS mailing list <centos at centos.org> > Date: Friday, July 02, 2010 7:33:45 AM >> Finnur Örn Guðmundsson wrote: >> >>> On Cisco switches it would be called "native vlan" if i remember correctly: >>> >>> One way of doing it (if using Cisco :): >>> >>> interface GigabitEthernet0/1 >>> description nodeX >>> switchport trunk native vlan 100 >>> switchport trunk allowed vlan 100,101 >>> switchport mode trunk >>> spanning-tree portfast trunk >>> spanning-tree bpdufilter enable >>> end >>> >>> >> Doing it that way would force you to change all of your switches and hosts that >> know about vlan 100 at once. You might also add native (untagged) vlan 1 to the >> existing tagged vlans - then you can set up a pxe-booting network on vlan 1 and >> once things are installed you can add the tagged vlan interfaces and optionally >> remove the IP address from the untagged (base eth device) interface. >> > No, these are per port settings and do not require coordinated changes > to any other switches, switch ports, or hosts. With the proposed config, > untagged data between the host and switch would be processed as VLAN 100 > - unbeknownst to the host. The host would have the base eth device setup > without VLANs - this is VLAN 100. Any additional VLANs are setup as > normal eth.vlanXX devices. As was said, this is just one way of doing > things. > > Personally, I might propose that PXE setup be performed on a dedicated > VLAN, once the server is setup it would then utilize a different set of > VLANs for communication. > > --Blake > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos >