puppet-network icon indicating copy to clipboard operation
puppet-network copied to clipboard

network_config should support vlan interfaces

Open jhoblitt opened this issue 12 years ago • 3 comments

It's highly desirable to be able to configure tagged vlan interfaces for a multiple of reasons but in particular when configuring a host to act as a Linux kernel based hypervisor. In the specific hypervisor scenario (under linux) there is normally a chain of interfaces like:

eth0 (raw interface) -> eth0.100 (802.1q tagged interfaces) -> br100 (bridge interface)

or

eth0/eth1/etc. (raw interfaces) -> bond0 (bond interface) -> eth0.100 (802.1q tagged interfaces) -> br100 (bridge interface)

The $::osfamily == debian and redhat configuration file approach for modeling the the relationship of the raw interfaces and the vlan interface are flexible but there is at least one syntax that is fairly similar between them.

On redhat, the ifcfg configuration file DEVICE variable provides both the name of the parent raw device and the vlan tag ID. The VLAN variable also needs to be declared to invoke this magic device name parsing (it has not be tested if it it works without doing this but the VLAN variable is required per the rhel documenation)

DEVICE=ethX.192
..
VLAN=yes

(from: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/s2-networkscripts-interfaces_802.1q-vlan-tagging.html)

On debian, the iface declaration seems to declare the vlan tag (similar to the redhat DEVICE variable) but doesn't auto-magically seem to imply the parent raw device. A separate sub declaration of vlan-raw-device is needed.

iface eth0.110 inet manual
        vlan-raw-device eth0

(from: http://wiki.debian.org/NetworkConfiguration#Howto_use_vlan_.28dot1q.2C_802.1q.2C_trunk.29_.28Etch.2C_Lenny.29)

jhoblitt avatar Jul 22 '13 19:07 jhoblitt

Here's some thoughts on a possible [simple] implementation of vlan support into network_config.

  • add a new boolean parameter to the network_config type called vlan; an alternative possibility would be add some sort of parameter to declare the type of the interface. Eg. raw|bond|bridge|vlan
  • the debian & redhat providers would both need to be modified to parse the namevar and or the device name into a raw interface name part and a vlan ID part, if the vlan parameter is true.
  • in the redhat provider the "vlanness" of an interface could be be detected by either parsing the filename directly or the device variable in the per interface configuration. It seems that perhaps parsing the device variable would be slightly simpler, only requiring a small hook in parse_file instead of having to build two separate lists of files. If it was desired to validate the format of the files being parsed, it might be easier to do it the other way around and track the name of the file that was parsed to valid the device var in general. No modification of format_file/etc. should be necessary if we are requiring the vlan param on the type to be set.
  • in the debian provider the Instance.initialize method looks like a good place to parse the name into raw & vlan tagged components. format_file would need to be modified to inject the vlan-raw-device line.

Thoughts/comments/criticisms?

jhoblitt avatar Jul 22 '13 22:07 jhoblitt

Off issue discussed with @adrienthebo has resulted in the conclusion that it makes more sense to add a parameter to set the type of interface that's being configured. eg, vlan|bridge|bond as these states seem to be mutually exclusive, at least under the linux kernel.

jhoblitt avatar Jul 22 '13 22:07 jhoblitt

Hello:

What's the status of this issue? I'm just pinging old issues. Is this possibly related to #98?

jyaworski avatar May 02 '16 04:05 jyaworski