[CentOS] Kickstart from tagged VLAN?

Fri Jul 9 06:32:06 UTC 2010
Jeff Hefner <jeffhefner at gmail.com>

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=
netmask= gateway= dns=
My previously supplied link had a link to this article about Anaconda
being enhanced to support VLANs:


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.

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