According to the product guide [1], the vlan naming scheme should be ${parent-iface}.${vlan-id}. Is there any particular reason for having a custom naming scheme instead of a documented one?

When I use the documented naming, I get a different interface config which is usable (see the screenshots). It does not contain 'NAME', so I will take this as a feature request to add it.


[1] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/networking_guide/sec-configure_802_1q_vlan_tagging_using_the_command_line

Created attachment 1501754 [details]
unusable vlan

Created attachment 1501755 [details]
usable vlan

Created redmine issue http://projects.theforeman.org/issues/25388 from this bug

Ondřej,
  I may have made an incorrect assumption with a behavior that I observed with Satellite 6.3.  When I added a new host to Satellite using bootstrap.py, Satellite discovered the interface identifier for the virtual interface in the format of "vlan3", not "em1.3".  I used "nmcli" to add the interfaces, so I didn't directly modify the network-script files to configure the interface.  An example of how I configured an interface (note, the example below is for a differet Host since the origional host is no longer available for troubleshooting):

host2# nmcli connection add type vlan ifname VLAN201 dev enp6s0 id 201 ip4 10.20.30.50/24 gw4 10.20.30.1

host2# ip addr
...
2: enp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether aa:bb:cc:dd:ee:df brd ff:ff:ff:ff:ff:ff
    inet6 .../64 scope link 
       valid_lft forever preferred_lft forever
...
4: VLAN201@enp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether aa:bb:cc:dd:ee:df brd ff:ff:ff:ff:ff:ff
    inet 10.20.30.50/24 brd 10.20.30.255 scope global noprefixroute VLAN201
       valid_lft forever preferred_lft forever
    inet6 .../64 scope link 
       valid_lft forever preferred_lft forever

host2# cat /etc/sysconfig/network-scripts/ifcfg-vlan-VLAN201 
VLAN=yes
TYPE=Vlan
PHYSDEV=enp6s0
VLAN_ID=201
REORDER_HDR=yes
GVRP=no
MVRP=no
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=none
IPADDR=10.20.30.50
PREFIX=24
GATEWAY=10.20.30.1
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=no
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
IPV6_ADDR_GEN_MODE=stable-privacy
NAME=vlan-VLAN201
UUID=...
DEVICE=VLAN201
ONBOOT=yes
DNS1=10.20.30.2
DNS2=10.20.30.3


# hammer host interface list --host host2.example.com 
----|------------|--------------------------------|-------------------|------------|-------------------
ID  | IDENTIFIER | TYPE                           | MAC ADDRESS       | IP ADDRESS | DNS NAME          
----|------------|--------------------------------|-------------------|------------|-------------------
200 | vlan201    | interface                      |                   |            |                   
201 | enp7s0     | interface                      | aa:bb:cc:dd:ee:ff |            |                   
199 | enp6s0     | interface (primary, provision) | aa:bb:cc:dd:ee:df |            | host2.example.com
----|------------|--------------------------------|-------------------|------------|-------------------

  Using Satellite, re-provisioned the above host (host2) using a new Host profile in Satellite using "enp6s0.201" as the interface identifier, and I get a usable network configuration, but I still get the same "sed" error and some interesting "ifcfg-" files in /etc/sysconfig/network-scripts:

host2# ls /etc/sysconfig/network-scripts/ifcfg-*
/etc/sysconfig/network-scripts/ifcfg-
/etc/sysconfig/network-scripts/ifcfg-enp6s0 vlan201@enp6s0
/etc/sysconfig/network-scripts/ifcfg-lo
/etc/sysconfig/network-scripts/ifcfg-enp6s0
/etc/sysconfig/network-scripts/ifcfg-enp7s0
/etc/sysconfig/network-scripts/ifcfg-vlan201

host2# cat /etc/sysconfig/network-scripts/ifcfg-
BOOTPROTO="none"
IPADDR="10.20.30.50"
NETMASK="255.255.255.0"
GATEWAY="10.20.30.1"
DEVICE=
ONBOOT=yes
PEERDNS=yes
PEERROUTES=yes
DEFROUTE=yes
DNS1="10.20.30.2"
DNS2="10.20.30.3"
VLAN=yes

host2# cat /etc/sysconfig/network-scripts/ifcfg-enp6s0\ vlan201@enp6s0 
BOOTPROTO="none"
DEVICE=enp6s0
vlan201@enp6s0
HWADDR="aa:bb:cc:dd:ee:df"
ONBOOT=yes
PEERDNS=no
PEERROUTES=no
DEFROUTE=no

host2# cat /etc/sysconfig/network-scripts/ifcfg-enp6s0
TYPE=Ethernet
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=dhcp
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
IPV6_ADDR_GEN_MODE=stable-privacy
NAME=enp6s0
UUID=38ccaa08-da98-45cc-a574-4d5dc2762e4e
DEVICE=enp6s0
ONBOOT=no

host2# cat /etc/sysconfig/network-scripts/ifcfg-vlan201 
# Generated by dracut initrd
NAME="vlan201"
ONBOOT="yes"
NETBOOT="yes"
UUID="662578ad-1b85-40b3-b66a-8e53365e3da7"
IPV6INIT="yes"
BOOTPROTO="none"
IPADDR="10.20.30.50"
NETMASK="255.255.255.0"
GATEWAY="10.20.30.1"
TYPE="Vlan"
DEVICE="vlan201"
VLAN="yes"
PHYSDEV="enp6s0"
DNS1="10.20.30.2"
VLAN_ID="201"
REORDER_HDR="yes"
GVRP="no"
MVRP="no"
PROXY_METHOD="none"
BROWSER_ONLY="no"
PREFIX="22"
DNS2="10.20.30.3"
DEFROUTE="yes"
IPV4_FAILURE_FATAL="no"
IPV6_AUTOCONF="yes"
IPV6_DEFROUTE="yes"
IPV6_FAILURE_FATAL="no"

host2# nmcli connection 
NAME                          UUID                                  TYPE      DEVICE  
System enp6s0 vlan201@enp6s0  db1a8b97-8024-cc23-5b0e-8ef65535038c  ethernet  enp6s0  
vlan201                       662578ad-1b85-40b3-b66a-8e53365e3da7  vlan      vlan201 
enp6s0                        38ccaa08-da98-45cc-a574-4d5dc2762e4e  ethernet  --      
enp7s0                        af930135-7a86-42ef-b2a5-926d9247ee06  ethernet  --      

host2# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
...
2: enp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether aa:bb:cc:dd:ee:df brd ff:ff:ff:ff:ff:ff
    inet6 .../64 scope link 
       valid_lft forever preferred_lft forever
3: enp7s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
    link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff
4: vlan201@enp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether aa:bb:cc:dd:ee:df brd ff:ff:ff:ff:ff:ff
    inet 10.20.30.50/24 brd 10.20.30.255 scope global noprefixroute vlan201
       valid_lft forever preferred_lft forever
    inet6 .../64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

  My observation of the "kickstart_ifcfg_get_identifier_names" template is it still does not produce usable interface configurations.  In this case, it seems the usable configuration comes from "ifcfg-vlan201", which is apparently generated by Dracut.  Is the "kickstart_ifcfg_get_identifier_names" required for RHEL 7 if Dracut configured the interface correctly?

  In any case, the provisioning template snippet uses an incorrect variable for the interface identifier (@identifier -> @interface.identifier).  If the interface identifier is set for the Host's interface, there is no need for the provisioning template generate one on its own.

satellite# rpm -qf /usr/share/foreman/app/views/unattended/provisioning_templates/snippet/_kickstart_ifcfg_get_identifier_names.erb
foreman-1.15.6.48-1.el7sat.noarch

Thanks
Matt LeSieur

Thank you for additional information. The snippet works correctly when creating new hosts directly in Satellite, but it seems to create a corrupted config when reprovisioning hosts imported with bootstrap.py. I think the script may import the interfaces in such a way that the snippet just can't figure out the correct names and deploys corrupted config.

Dracut auto-created a correct config, because the one deployed by Satellite did not have a proper name. If Dracut configured the interface correctly then you can modify the template not to use the snippet as a workaround for this particular case.

Ondřej,
  In both cases I outlined above where a host was provisioned from Satellite, I created a new host using "Host -> Create Host".  I did not reuse a host profile that was already present in Satellite.

  I believe one of the difficulties that the snippet has is when there multiple interfaces on the server, which is always the case when a server uses tagged VLANs (e.g. eth0 and eth0.3).  The "ifcfg-enp6s0\ vlan201@enp6s0" interface configuration above demonstrates how lost the script is with multiple interfaces.  I have not observed these interface problems when provisioning servers using virtual machines with one interface.

  I also want to point out that the Puppet agent on the server is reporting the "vlan#" style interface name for a server to Satellite.  The "/opt/puppetlabs/bin/facter" programs returns "vlan201" and not "enp6s0.201" for a tagged interface, which then populates server interface in Satellite.  This is a whole other problem in itself, but I figure I would just point it out here since it may be relevant.

  I can definitely find a workaround for this problem, but ultimately, Satellite must be able to configure interfaces on a provisioned server correctly.  AFAIK, tagged VLANs are not an edge case and should be handled properly by Satellite.

Thanks
Matt LeSieur

Ondřej,
  I made an error in my last comment.  The problem is _not_ that there are multiple interfaces on the server, but that there are multiple interfaces with the same MAC address.  This situation happens with interfaces are configured for tagged VLANs.  Continuing with the example above from "host2", the snippet is expecting one interface to be returned, but the code returns two interfaces:

host2# ip -o link 
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000\    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000\    link/ether aa:bb:cc:dd:ee:df brd ff:ff:ff:ff:ff:ff
3: enp7s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP mode DEFAULT group default qlen 1000\    link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff
4: vlan201@enp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000\    link/ether aa:bb:cc:dd:ee:df brd ff:ff:ff:ff:ff:ff

host2# ip -o link | awk '/aa:bb:cc:dd:ee:df/ {print $2;}' | sed s/:$//
enp6s0
vlan201@enp6s0

  Only one interface should be returned, but you can see that two are returned because both the parent and VLAN interface share the same MAC address.

Thanks
Matt LeSieur

The Satellite Team is attempting to provide an accurate backlog of bugzilla requests which we feel will be resolved in the next few releases. We do not believe this bugzilla will meet that criteria, and have plans to close it out in 1 month. This is not a reflection on the validity of the request, but a reflection of the many priorities for the product. If you have any concerns about this, feel free to contact Red Hat Technical Support or your account team. If we do not hear from you, we will close this bug out. Thank you.

 Thanks for taking the time to look into this bug.  Not many sites provision bare-metal servers anymore, so it is understandable that putting effort into fixing provisioning problems for bare-metal servers in Satellite is not a priority.  Also, Dracut seems to provision the interface configuration correctly, so ultimately this problem is cosmetic.  The interface configuration files that the provisioning template write can be removed manually since they do not do anything.  Again, Dracut produces a working network configuration.  Just to review, the three items I point out in this BZ are:

1. Dracut produces a working network configuration.  Is this provisioning template snippet needed anymore?
2. The provisioning template code to produce the interface name assumes only one interface per MAC address but when a tagged VLAN is present, the host will have a parent and VLAN interface with the same MAC address.
3. Building a host from Satellite requires interface names in the format of enp6s0.201 while Puppet (facter) updates the host interface configuration using the format vlan201.  The provisioning template snippet uses "ip link", which reports the interface name as vlan201@enp6s0.

Thanks
Matthew LeSieur

Thank you for your interest in Satellite 6. We have evaluated this request, and while we recognize that it is a valid request, we do not expect this to be implemented in the product in the foreseeable future. This is due to other priorities for the product, and not a reflection on the request itself. We are therefore closing this out as WONTFIX. If you have any concerns about this, please do not reopen. Instead, feel free to contact Red Hat Technical Support. Thank you.

Hello, this appeared when we were talking about similar bug. Let me clear some things:

>The template "kickstart_ifcfg_get_identifier_names" includes an "if" statement to check if the interface identifier is defined.  The code is using the wrong >variable name to check if the identifier is set.

It is actually correct, the snippet you mention lives in 

https://github.com/theforeman/foreman/blob/b49848385eab6b500b41b0b1db5491ccdd046caf/app/views/unattended/provisioning_templates/snippet/kickstart_ifcfg_get_identifier_names.erb

which is called from here

https://github.com/theforeman/foreman/blob/f7e8785ba53f793ca1ab847bdeb1fa07b77da1d7/app/views/unattended/provisioning_templates/snippet/kickstart_networking_setup.erb

As you can see both @interface and @identifier are passed as custom variables and the latter is used when it's virtual interface (has attached_to), for example a bond or vlan.

<%- if @identifier -%>
<%=   "real=\"#{@identifier}\"" %>
<%- else -%>

This is root of the problem, when a host is created from scratch in Satellite, then interfaces has the correct relationship. In this case master-slave relationship between the regular and the virtual (VLAN) interface. Everything works fine.

Now, when a host is imported using puppet facts, subscription manager or any other supported fact input, Satellite tries its best to "guess" the relationship for NICs. Both puppet facter and rhsm sends only few facts, e.g. MAC address and identifier, this does not include more detailed (netlink) information about relationships and this is on our radar to fix this in the future. However today, Satellite perform heuristic detection of these interfaces, for example identifier in the form of X.Y is seen as a VLAN interface and it attaches to the regular interface that matches the indentifier before the dot. Similarly, bondX is a bond interface etc. However, if a virutal identifier does not match the regular expression which is embedded in the Satellite codebase, it will get detected as another regular interface and this is where problem triggers. Here are the regular expressions:

https://github.com/theforeman/foreman/blob/a65a7312baaf85da710be9ad98626e9a592573c3/app/services/fact_parser.rb#L3-L8

Historically, Red Hat systems VLAN identifier naming convention uses the dot dotation (eth0.42), after NetworkManager it's more common these days to use "vlan42" form where relationship is not captured. The only solution to this problem is to extend facts reported by some tools to include netlink information with relationships.

Before performing provisioning, make sure the virtual interface has "attached to" set properly, has "virtual" flag and also it has the correct identifier.