Is 802.1q tagged VLAN support available in Red Hat Enterprise Linux 8/7/6/5 anaconda?
Environment
- Red Hat Enterprise Linux 8
- Red Hat Enterprise Linux 7
- Red Hat Enterprise Linux 6
- Red Hat Enterprise Linux 5
Issue
- Does Red Hat Enterprise Linux 8/7/6/5
anaconda
support802.1q tagged vlan
during installation? - Can one setup
802.1q tagged vlan
IP for an interface onanaconda
command line? - What is the syntax of declaring
vlan
onanaconda
command line and inside kickstart file?
Resolution
Red Hat Enterprise Linux 8
- Red Hat Enterprise Linux 8 fully supports
802.1q tagged vlan
configuration onanaconda
command line as well as inside kickstart. - The
anaconda
command line syntax can be as follows for802.1q tagged vlan
information along with kickstart path
inst.ks=<network path for kickstart> bootdev=<device>.<vlanID> ifname=<device>:<MAC> vlan=<device>.<vlanID>:<device> ip=<client-IP>::<gateway-IP>:<netmask>:[<hostname>]:<device>.<vlanID>:none
- The
anaconda
command line example can be setup as follows. Replace all fields wherever necessary.
inst.ks=http://192.168.0.1/ks.cfg bootdev=ens3.100 ifname=ens3:7c:d3:0a:xx:yy:zz vlan=ens3.100:ens3 ip=192.168.0.100::192.168.0.1:255.255.255.0:testhostname:ens3.100:none
- Inside kickstart file, the
network
line can be as follows.
network --bootproto=static --device=ens3 --gateway=192.168.0.1 --ip=192.168.0.100 --netmask=255.255.255.0 --noipv6 --vlanid 100
- Red Hat Enterprise Linux 8 now doesn't support traditional
ip=<IP> gateway=<GW> netmask=<NM>
now, so use only above format. See this Solution for details.
Red Hat Enterprise Linux 7
- Red Hat Enterprise Linux 7 too supports
802.1q tagged vlan
configuration like above. - Syntax and examples can be exactly same as mentioned for Red Hat Enterprise Linux 8, whereas Red Hat Enterprise Linux 7 still supports traditional
ip=<IP> gateway=<GW> netmask=<NM>
format onanaconda
command line as follows.
inst.ks=<network path for kickstart> bootdev=<device>.<vlanID> ifname=<device>:<MAC> vlan=<device>.<vlanID>:<device> ip=<client-IP> gateway=<gateway-IP> netmask=<netmask> hostname=<hostname>
- Kickstart
network
command is same too.
network --bootproto=static --device=ens3 --gateway=192.168.0.1 --ip=192.168.0.100 --netmask=255.255.255.0 --noipv6 --vlanid 100
Red Hat Enterprise Linux 6
- Red Hat Enterprise Linux 6.9 fully supports
802.1q tagged vlan
during deployment. - In Red Hat Enterprise Linux 6.4, the
vlanid=
boot option and the--vlanid=
kickstart option allows to set a virtual LAN ID (802.1q tag
) for a specified network device. - By specifying either one of these options, installation of the system can be done over a VLAN.
- This was achieved through an Errata RHBA-2013-0373.
- Unfortunately, the kickstart option may not work even in Red Hat Enterprise Linux 6.4. There was a bug in Red Hat Enterprise Linux 6.4 which is fixed in Red Hat Enterprise Linux 6.5. For more details, Refer Solution #331563.
- The following
anaconda
command line options can be used post Red Hat Enterprise Linux 6.5
ks=<network path for kickstart> ksdevice=<device>.<vlanID> vlanid=<vlanID> ip=<client-IP> gateway=<gateway-IP> netmask=<netmask> hostname=<hostname>
- The kickstart
network
line will be as follows.
network --bootproto=static --device=eth0 --gateway=192.168.0.1 --ip=192.168.0.100 --netmask=255.255.255.0 --noipv6 --vlanid 100
Red Hat Enterprise Linux 5
- Red Hat Enterprise Linux 5 does not support
802.1q tagged VLANs
in kickstart.
This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.
2 Comments
Some of our non-virtualized machines require several ethernet connections going over the same high end switches which use vlan taging to separate the network traffic further up the chain. In our environment we are having to contact the network admins and have them change swith ports for 802.1q trunking temporarly to an "access port" configuration for the installs then back to 802.1q trunking afterwards. We are not allowed to use native vlans for "security reasons", so a days worth of work can turn into a month or so in a large organization when dealing with the network department to get a simple network install completed. Having the ability to specify a vlan for the installation portion in anaconda would be a great option that would save both time and money.
Second. We also have a similar environment, and by the sounds of it, a similar networking dept. Adding vlan=xxx for kickstart would be most welcomed. If the .1q module is already available in the ram disk along with the ethernet modules I would have thought that using vlans for the OS installation would be possible?