I've searched around but haven't found a definitive answer yet, is it possible to kickstart from a tagged VLAN? I found this bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=431915
But I can't find out how far the vlan support goes. I haven't found anything about it in any kickstart docs.
I have two tagged vlans:
Vlan 100 - server subnet Vlan 101 - backup subnet
From start to finish anaconda needs to pick up a dynamic address from vlan 100. After that the kickstart file specifies the static adress from vlan100 and it's address from the backup subnet. Anyone know if this is currently possible? If so any nod in the right direction would be appreciated
Jeff
On 07/01/10 3:51 PM, Jeff Hefner wrote:
I've searched around but haven't found a definitive answer yet, is it possible to kickstart from a tagged VLAN? I found this bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=431915
But I can't find out how far the vlan support goes. I haven't found anything about it in any kickstart docs.
I have two tagged vlans:
Vlan 100 - server subnet Vlan 101 - backup subnet
From start to finish anaconda needs to pick up a dynamic address from vlan 100. After that the kickstart file specifies the static adress from vlan100 and it's address from the backup subnet. Anyone know if this is currently possible? If so any nod in the right direction would be appreciated
I dunno how you'd get the BIOS to do a PXE boot off a vlan.
From start to finish anaconda needs to pick up a dynamic address from vlan 100. After that the kickstart file specifies the static adress from vlan100 and it's address from the backup subnet. Anyone know if this is currently possible? If so any nod in the right direction would be appreciated
I dunno how you'd get the BIOS to do a PXE boot off a vlan.
I remember running into this a while ago. I think most multi-layer switches can have a default VLAN that untagged packets will go to. Check the docs for your switch.
Scott
On 2.7.2010 04:46, Scott Beardsley wrote:
From start to finish anaconda needs to pick up a dynamic address from vlan 100. After that the kickstart file specifies the static adress from vlan100 and it's address from the backup subnet. Anyone know if this is currently possible? If so any nod in the right direction would be appreciated
I dunno how you'd get the BIOS to do a PXE boot off a vlan.
I remember running into this a while ago. I think most multi-layer switches can have a default VLAN that untagged packets will go to. Check the docs for your switch.
Scott _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
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
Bgrds, Finnur
Finnur Örn Guðmundsson wrote:
On 2.7.2010 04:46, Scott Beardsley wrote:
From start to finish anaconda needs to pick up a dynamic address from vlan 100. After that the kickstart file specifies the static adress from vlan100 and it's address from the backup subnet. Anyone know if this is currently possible? If so any nod in the right direction would be appreciated
I dunno how you'd get the BIOS to do a PXE boot off a vlan.
I remember running into this a while ago. I think most multi-layer switches can have a default VLAN that untagged packets will go to. Check the docs for your switch.
Scott _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
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.
-- Les Mikesell lesmikesell@gmail.com
-------- Original Message -------- Subject: Re: [CentOS] Kickstart from tagged VLAN? From: Les Mikesell lesmikesell@gmail.com To: CentOS mailing list centos@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
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@ispn.net wrote:
-------- Original Message -------- Subject: Re: [CentOS] Kickstart from tagged VLAN? From: Les Mikesell lesmikesell@gmail.com To: CentOS mailing list centos@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@centos.org http://lists.centos.org/mailman/listinfo/centos
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.
On Friday, July 02, 2010 06:51 AM, Jeff Hefner wrote:
I've searched around but haven't found a definitive answer yet, is it possible to kickstart from a tagged VLAN? I found this bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=431915
But I can't find out how far the vlan support goes. I haven't found anything about it in any kickstart docs.
I have two tagged vlans:
Vlan 100 - server subnet Vlan 101 - backup subnet
From start to finish anaconda needs to pick up a dynamic address from vlan 100. After that the kickstart file specifies the static adress from vlan100 and it's address from the backup subnet. Anyone know if this is currently possible? If so any nod in the right direction would be appreciated
Set the port to vlan 100 untagged and when the installation is done, switch it back tagged - assuming your kickstart script sets up the vlans...
-
Blake Hudson -
Christopher Chan -
Finnur Örn Guðmundsson -
Jeff Hefner -
John R Pierce -
Les Mikesell -
Scott Beardsley