Bug 1101795 - vconfig initializes virtual alias interfaces
Summary: vconfig initializes virtual alias interfaces
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: initscripts
Version: 6.5
Hardware: Unspecified
OS: Linux
urgent
urgent
Target Milestone: rc
: ---
Assignee: Lukáš Nykrýn
QA Contact: Jan Ščotka
URL:
Whiteboard:
Depends On:
Blocks: 1111638 1111639
TreeView+ depends on / blocked
 
Reported: 2014-05-27 23:29 UTC by Terry Bowling
Modified: 2018-12-06 16:37 UTC (History)
5 users (show)

Fixed In Version: initscripts-9.03.43-1.el6
Doc Type: Bug Fix
Doc Text:
Prior to this update, the udev device manager called the hotplug script when a Virtual LAN (VLAN) network was added. However, because the VLAN network has the same default hardware address as the default network adapter device, hotplug reverted the network adapter's IP configuration to the values in the /etc/sysconfig/network-scripts/ directory, and in some cases caused the network adapter to go offline. This update removes the triggering of the hotplug script for VLAN networks and as a result, the network adapter now retains its IP address and thus no longer fails.
Clone Of:
: 1111638 1111639 (view as bug list)
Environment:
Last Closed: 2014-10-14 06:28:35 UTC
Target Upstream Version:


Attachments (Terms of Use)
hotplug patch (1011 bytes, patch)
2014-06-05 08:07 UTC, Lukáš Nykrýn
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 886653 0 None None None Never
Red Hat Product Errata RHBA-2014:1448 0 normal SHIPPED_LIVE initscripts bug fix and enhancement update 2014-10-14 01:05:44 UTC

Description Terry Bowling 2014-05-27 23:29:27 UTC
Description of problem:

Both vconfig and ip link commands, when adding a vlan alias interface to eth1, cause eth1:1 to be reverted back to the settings defined in /etc/sysconfig/network-scripts/ifcfg-eth1:1, even when eth1:1 was manually changed with the ip command to have a different IP address.

VERY CONCERNING is the fact that if ONPARENT=no, it will OFFLINE eth1:1, potentially causing a disruptive outage.


Version-Release number of selected component (if applicable):

RHEL 6.4 EUS
vconfig-1.9-8.1.el6.x86_64
iproute-2.6.32-23.el6.x86_64


How reproducible:

Very simple to reproduce in a virtual machine using a secondary eth1 interface.


Steps to Reproduce:

1. Configure eth1 and eth1:1 according to the following config files:

2. Bring up eth1 and eth:1, ONPARENT=yes

	ifup eth1


3. Verify interfaces eth1 and eth1:1 (10.8.1.1)
	ip addr show dev eth1:1

        inet 10.8.33.1/20 brd 10.8.47.255 scope global eth1
->      inet 10.8.1.1/20 scope global eth1:1


4. Change eth1:1 to use a different IP from what is in ifcfg-eth1:1 (10.8.17.1)

	ip addr add 10.8.17.1/20  label 'eth1:1' dev eth1
	ip addr del 10.8.1.1/20 dev eth1:1
	ip addr show dev eth1:1

        inet 10.8.33.1/20 brd 10.8.47.255 scope global eth1
->      inet 10.8.17.1/20 scope global eth1:1


5. Add vlan 3999 interface to eth1
	modprobe 8021q
	vconfig add eth1 3999

	Added VLAN with VID == 3999 to IF -:eth1:-

6. Verify and see that eth1:1 was changed back to the default ip in ifcfg-eth1:1 (10.8.1.1)

	ip addr show dev eth1:1
	inet 10.8.33.1/20 brd 10.8.47.255 scope global eth1
->	inet 10.8.1.1/20 brd 10.8.15.255 scope global eth1:1


7. Same problem when using ip link command instead of vconfig

	ip link add link eth1 name eth1.3999 type vlan id 3999


Actual results:

eth1:1 is reset to IP address 10.8.1.1
	ip addr show dev eth1:1
	inet 10.8.33.1/20 brd 10.8.47.255 scope global eth1
->	inet 10.8.1.1/20 brd 10.8.15.255 scope global eth1:1


Expected results:

eth1:1 would retain IP address 10.8.17.1

	ip addr show dev eth1:1
        inet 10.8.33.1/20 brd 10.8.47.255 scope global eth1
->      inet 10.8.17.1/20 scope global eth1:1


Additional info:

 * This option does not help:
	echo "1" > /proc/sys/net/ipv4/conf/eth1/promote_secondaries

 * Using ONPARENT=no offlines eth1:1

 * Using ONPARENT=yes reverts manually set IP configuration with the config file settings,

Comment 1 Terry Bowling 2014-05-27 23:30:05 UTC
Keeping BZ public to provide visibility to the customer.

Comment 3 Terry Bowling 2014-05-27 23:31:46 UTC
Setting urgent as it will very soon impact customer product delivery date.

Comment 4 Petr Pisar 2014-05-28 06:23:13 UTC
According to your report, this happens with either vconfig or ip. So this has nothing to do with vconfig component. So the bug is somewhere else. This is supported by the fact that vconfig tool does not touch network addresses at all. It only calls an IOCTL to create or remove a VLAN device.

This bug could be in kernel or some network management daemon you possibly use.
In addition, I cannot reproduce this problem on RHEL-6.5 with 2.6.32-431.el6.x86_64 kernel. Maybe because my system does not use Network Manager.

For further investigation, I need to know which kernel version do use use (uname -r) and what version of initscripts you have installed (rpm -q initscripts). Also I need to know if you are running the Network Manager and if you are, then what version (rpm -q NetworkManager).

Comment 5 Saul Serna 2014-05-29 23:18:44 UTC
Hi Petr,

Here are the customers environment specifics you requested. NetworkManager doesnt appear to be running.


(uname -r)
-------------------------
2.6.32-358.23.2.el6.x86_64


(rpm -q initscripts)
-------------------------
initscripts-9.03.38-1.el6_4.2.x86_64          Fri May  9 06:19:15 2014


# more chkconfig | egrep "Network|network"
------------------------------------------
network        	0:off	1:off	2:on	3:on	4:on	5:on	6:off



Saul

Comment 6 Terry Bowling 2014-05-30 01:14:38 UTC
#24 Created By: Robb Manes  (5/27/2014 4:56 PM) Last Modified By: Robb Manes  (5/27/2014 5:06 PM) 

On a whim, I changed the IP address of the eth1:1 interface mid-test to see if it reads the file.  Turns out, yes, it does, as it assigned it the new address from the script, not one I had ever manually typed at one point (except into the ifcfg-* file).

So, it appears that, most likely, vconfig is re-parsing the ifcfg files.

# rpm -qa | grep vconfig
vconfig-1.9-8.1.el6.x86_64

It doesn't do a lot upon execution either:

# strace -Tttvfs 1024 -o /tmp/vconfig.out vconfig add eth1 3999
Added VLAN with VID == 3999 to IF -:eth1:-

3690  16:33:00.892662 execve("/sbin/vconfig", ["vconfig", "add", "eth1", "3999"], ["HOSTNAME=rhel64eus", "SELINUX_ROLE_REQUESTED=", "TERM=xterm-256color", "SHELL=/bin/bash", "HISTSIZE=1000", "SSH_CLIENT=192.168.122.1 43801 22", "SELINUX_USE_CURRENT_RANGE=", "SSH_TTY=/dev/pts/1", "USER=root", "LS_COLORS=rs=0:di=38;5;27:ln=38;5;51:mh=44;38;5;15:pi=40;38;5;11:so=38;5;13:do=38;5;5:bd=48;5;232;38;5;11:cd=48;5;232;38;5;3:or=48;5;232;38;5;9:mi=05;48;5;232;38;5;15:su=48;5;196;38;5;15:sg=48;5;11;38;5;16:ca=48;5;196;38;5;226:tw=48;5;10;38;5;16:ow=48;5;10;38;5;21:st=48;5;21;38;5;15:ex=38;5;34:*.tar=38;5;9:*.tgz=38;5;9:*.arj=38;5;9:*.taz=38;5;9:*.lzh=38;5;9:*.lzma=38;5;9:*.tlz=38;5;9:*.txz=38;5;9:*.zip=38;5;9:*.z=38;5;9:*.Z=38;5;9:*.dz=38;5;9:*.gz=38;5;9:*.lz=38;5;9:*.xz=38;5;9:*.bz2=38;5;9:*.tbz=38;5;9:*.tbz2=38;5;9:*.bz=38;5;9:*.tz=38;5;9:*.deb=38;5;9:*.rpm=38;5;9:*.jar=38;5;9:*.rar=38;5;9:*.ace=38;5;9:*.zoo=38;5;9:*.cpio=38;5;9:*.7z=38;5;9:*.rz=38;5;9:*.jpg=38;5;13:*.jpeg=38;5;13:*.gif=38;5;13:*.bmp=38;5;13:*.pbm=38;5;13:*.pgm=38;5;13:*.ppm=38;5;13:*.tga=38;5;13:*.xbm=38;5;13:*.xpm=38;5;13:*.tif=38;5;13:*.tiff=38;5;13:*.png=38;5;13:*.svg=38;5;13:*.svgz=38;5;13:*.mng=38;5;13:*.pcx=38;5;13:*.mov=38;5;13:*.mpg=38;5;13:*.mpeg=38;5;13:*.m2v=38;5;13:*.mkv=38;5;13:*.ogm=38;5;13:*.mp4=38;5;13:*.m4v=38;5;13:*.mp4v="..., "MAIL=/var/spool/mail/root", "PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin", "PWD=/etc/sysconfig/network-scripts", "XMODIFIERS=@im=ibus", "LANG=en_US.UTF-8", "SELINUX_LEVEL_REQUESTED=", "HISTCONTROL=ignoredups", "SHLVL=1", "HOME=/root", "LOGNAME=root", "CVS_RSH=ssh", "SSH_CONNECTION=192.168.122.1 43801 192.168.122.186 22", "LESSOPEN=|/usr/bin/lesspipe.sh %s", "G_BROKEN_FILENAMES=1", "_=/usr/bin/strace", "OLDPWD=/root"]) = 0 <0.000249>
3690  16:33:00.893168 brk(0)            = 0x1860000 <0.000007>
3690  16:33:00.893218 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f634823d000 <0.000008>
3690  16:33:00.893263 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) <0.000009>
3690  16:33:00.893310 open("/etc/ld.so.cache", O_RDONLY) = 3 <0.000010>
3690  16:33:00.893347 fstat(3, {st_dev=makedev(253, 0), st_ino=133495, st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=56, st_size=26824, st_atime=2014/05/27-11:40:01, st_mtime=2014/05/21-11:32:35, st_ctime=2014/05/21-11:32:35}) = 0 <0.000007>
3690  16:33:00.893396 mmap(NULL, 26824, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f6348236000 <0.000008>
3690  16:33:00.893425 close(3)          = 0 <0.000007>
3690  16:33:00.893471 open("/lib64/libc.so.6", O_RDONLY) = 3 <0.000010>
3690  16:33:00.893520 read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\355A\352=\0\0\0@\0\0\0\0\0\0\0(A\35\0\0\0\0\0\0\0\0\0@\0008\0\n\0@\0M\0L\0\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0@\352=\0\0\0@\0@\352=\0\0\0000\2\0\0\0\0\0\0000\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\0\0\0\236\25\0\0\0\0\0\0\236U\352=\0\0\0\0\236U\352=\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0@\352=\0\0\0\0\0@\352=\0\0\0000\225\30\0\0\0\0\0000\225\30\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\0\227\30\0\0\0\0\0\0\227x\352=\0\0\0\0\227x\352=\0\0\0\230F\0\0\0\0\0\0\250\221\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0@\313\30\0\0\0\0\0@\313x\352=\0\0\0@\313x\352=\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0p\2\0\0\0\0\0\0p\2@\352=\0\0\0p\2@\352=\0\0\0D\0\0\0\0\0\0\0D\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0\0\227\30\0\0\0\0\0\0\227x\352=\0\0\0\0\227x\352=\0\0\0\20\0\0\0\0\0\0\0h\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\0\0\0\34\236\25\0\0\0\0\0\34\236U\352=\0\0\0\34\236U\352=\0\0\0\374e\0\0\0\0\0\0\374e\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0R\345td\4\0\0\0\0\227\30\0\0\0\0\0\0\227x\352=\0\0\0\0\227x\352=\0\0\0\0009\0\0\0\0\0\0\0009\0\0\0\0\0\0\1\0\0\0\0\0\0\0\4\0\0\0\24\0\0\0\3\0\0\0GNU\0\357\35\315<\254Dq~\376\265\261,l~\3407\266\355\334\0\4\0\0\0\20\0\0\0\1\0\0\0GNU\0\0\0\0\0\2\0\0\0\6\0\0\0\22\0\0\0\0\0\0\0\363\3\0\0\t\0\0\0\0\1\0\0\16\0\0\0\0000\20D\240 \2\1\210\3\346\220\305E\214\0\300\0\10\0\5\200\0`\300\200\0\r\212\f\0\4\20\0\210D2\10.@\210P4, \16\"H&\204\300\214\4\10\0\2\2\16\241\254\32\4f\300\0\3002\0\300\0P\1 \201\10\204\v  ($\0\4 P\0\20X\200\312DB(\0\6\200\20\30B\0 @\200\0\tP\0Q\212@\20\0\0\0\0\10\0\0\21\20", 832) = 832 <0.000009>
3690  16:33:00.893696 fstat(3, {st_dev=makedev(253, 0), st_ino=147330, st_mode=S_IFREG|0755, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=3760, st_size=1922152, st_atime=2014/05/27-09:40:01, st_mtime=2013/09/03-16:27:20, st_ctime=2014/05/22-09:34:26}) = 0 <0.000006>
3690  16:33:00.893745 mmap(0x3dea400000, 3745960, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x3dea400000 <0.000052>
3690  16:33:00.893819 mprotect(0x3dea58a000, 2093056, PROT_NONE) = 0 <0.000009>
3690  16:33:00.893849 mmap(0x3dea789000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x189000) = 0x3dea789000 <0.000011>
3690  16:33:00.893887 mmap(0x3dea78e000, 18600, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x3dea78e000 <0.000012>
3690  16:33:00.893922 close(3)          = 0 <0.000006>
3690  16:33:00.893958 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6348235000 <0.000007>
3690  16:33:00.893991 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6348234000 <0.000007>
3690  16:33:00.894022 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6348233000 <0.000007>
3690  16:33:00.894050 arch_prctl(ARCH_SET_FS, 0x7f6348234700) = 0 <0.000006>
3690  16:33:00.894091 mprotect(0x3dea789000, 16384, PROT_READ) = 0 <0.000009>
3690  16:33:00.894120 mprotect(0x3de9e1f000, 4096, PROT_READ) = 0 <0.000008>
3690  16:33:00.894149 munmap(0x7f6348236000, 26824) = 0 <0.000011>
3690  16:33:00.894210 open("/proc/net/vlan/config", O_RDONLY) = 3 <0.000041>
3690  16:33:00.894278 close(3)          = 0 <0.000009>
3690  16:33:00.894310 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3 <0.000015>
3690  16:33:00.894351 ioctl(3, SIOCSIFVLAN, 0x7fffda086eb0) = 0 <0.001297>
3690  16:33:00.895689 fstat(1, {st_dev=makedev(0, 11), st_ino=4, st_mode=S_IFCHR|0620, st_nlink=1, st_uid=0, st_gid=5, st_blksize=1024, st_blocks=0, st_rdev=makedev(136, 1), st_atime=2014/05/27-16:33:00, st_mtime=2014/05/27-16:33:00, st_ctime=2014/05/27-16:18:18}) = 0 <0.000007>
3690  16:33:00.895743 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f634823c000 <0.000014>
3690  16:33:00.895791 write(1, "Added VLAN with VID == 3999 to IF -:eth1:-\n", 43) = 43 <0.000010>
3690  16:33:00.895835 exit_group(0)     = ?

vconfig.c

 96 int main(int argc, char** argv) {
 97    int fd;
 98    struct vlan_ioctl_args if_request;
 99 
100    char* cmd = NULL;
101    char* if_name = NULL;
102    unsigned int vid = 0;
103    unsigned int skb_priority;
104    unsigned short vlan_qos;
105    unsigned int nm_type = VLAN_NAME_TYPE_PLUS_VID;
106 
107    char* conf_file_name = "/proc/net/vlan/config";
108 
109    memset(&if_request, 0, sizeof(struct vlan_ioctl_args));
110 
111    if ((argc < 3) || (argc > 5)) {
[...]
116    }
117    else {
118       cmd = argv[1];
119
120       if (strcasecmp(cmd, "set_name_type") == 0) {
121          if (strcasecmp(argv[2], "VLAN_PLUS_VID") == 0) {
122             nm_type = VLAN_NAME_TYPE_PLUS_VID;
123          }
124          else if (strcasecmp(argv[2], "VLAN_PLUS_VID_NO_PAD") == 0) {
125             nm_type = VLAN_NAME_TYPE_PLUS_VID_NO_PAD;
126          }
127          else if (strcasecmp(argv[2], "DEV_PLUS_VID") == 0) {
128             nm_type = VLAN_NAME_TYPE_RAW_PLUS_VID;
129          }
130          else if (strcasecmp(argv[2], "DEV_PLUS_VID_NO_PAD") == 0) {
131             nm_type = VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD;
132          }
133          else {
134             // MATHIEU
135             //cerr << "Invalid name type.\n";
136             fprintf(stderr,"Invalid name type.\n");
137 
138             show_usage();
139             exit(1);
140          }
141          if_request.u.name_type = nm_type;
[...]
153 
154       if (argc == 4) {
155          vid = atoi(argv[3]);
156          if_request.u.VID = vid;
157       }
158 
159       if (argc == 5) {
160          skb_priority = atoi(argv[3]);
161          vlan_qos = atoi(argv[4]);
162          if_request.u.skb_priority = skb_priority;
163          if_request.vlan_qos = vlan_qos;
164       }
165    }
166 
167    // Open up the /proc/vlan/config
168    if ((fd = open(conf_file_name, O_RDONLY)) < 0) {
169       // MATHIEU
170       //cerr << "ERROR:  Could not open /proc/vlan/config.\n";
171       fprintf(stderr,"WARNING:  Could not open /proc/net/vlan/config.  Maybe you need to load the 8021q module, or maybe you are not using PROCFS??\n");
172 
173    }
[...]
184    /* add */
185    if (strcasecmp(cmd, "add") == 0) {
186       if_request.cmd = ADD_VLAN_CMD;
187       if (ioctl(fd, SIOCSIFVLAN, &if_request) < 0) {
188          fprintf(stderr,"ERROR: trying to add VLAN #%u to IF -:%s:-  error: %s\n",
189                     vid, if_name, strerror(errno));
190          exit(3);
191       }
192       else {
193          fprintf(stdout,"Added VLAN with VID == %u to IF -:%s:-\n",
194                  vid, if_name);
195          if (vid == 1) {
196             fprintf(stdout, "WARNING:  VLAN 1 does not work with many switches,\nconsider another number if you have problems.\n");
197          }
198       }

Okay, so I don't see where it forces a re-read of the initscripts, but obviously it has to at some point, or be a catalyst for it.  I wonder if playing with /proc/net/vlan/config will reset:

# cat /proc/net/vlan/config 
VLAN Dev name	 | VLAN ID
Name-Type: VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD
eth1.3999      | 3999  | eth1

Comment 7 Terry Bowling 2014-05-30 01:15:34 UTC
### Internal Note - Not for publish ### 
According to vconfig, the following source is responsible for this interaction:

http://opengrok.brq.redhat.com/source/xref/RHEL-6/vconfig/1.9/8.1.el6/vlan/vconfig.c
<snip>
     96 int main(int argc, char** argv) {
     97    int fd;
     98    struct vlan_ioctl_args if_request;
     99 
    100    char* cmd = NULL;
    101    char* if_name = NULL;
    102    unsigned int vid = 0;
    103    unsigned int skb_priority;
    104    unsigned short vlan_qos;
    105    unsigned int nm_type = VLAN_NAME_TYPE_PLUS_VID;
<snip>
    184    /* add */
    185    if (strcasecmp(cmd, "add") == 0) {
    186       if_request.cmd = ADD_VLAN_CMD;
    187       if (ioctl(fd, SIOCSIFVLAN, &if_request) < 0) {
    188          fprintf(stderr,"ERROR: trying to add VLAN #%u to IF -:%s:-  error: %s\n",
    189                     vid, if_name, strerror(errno));
    190          exit(3);
    191       }
    192       else {
    193          fprintf(stdout,"Added VLAN with VID == %u to IF -:%s:-\n",
    194                  vid, if_name);
    195          if (vid == 1) {
    196             fprintf(stdout, "WARNING:  VLAN 1 does not work with many switches,\nconsider another number if you have problems.\n");
    197          }
    198       }
    199    }//if

In the above, we see it just passed an "SIOCSIFVLAN" via ioctl(). This then travels down the following codepath once the appropriate hook is triggered on the kernel side:

register_vlan_device()
->register_vlan_dev()
 ->register_netdevice()


From the above, I would believe that we have a uevent being fired that is then causing the initscripts to be read back again. Still working to track down the specifics though. What happens if we add "HOTPLUG=no" to the interface scripts?

Kyle Walker
Global Support Services
North America

Comment 8 Terry Bowling 2014-05-30 01:16:10 UTC
Do the 2 comments above help answer your questions?  I will test the HOTPLUG=no option tomorrow.

Comment 9 Petr Pisar 2014-05-30 08:56:30 UTC
I downgraded kernel, initscripts, and iproute to versions you specified. I also downgraded udev to latest RHEL-6.4 EUS version (udev-147-2.46.el6_4.4). Despite that I cannot reproduce the problem. Also the content of /etc/sysconfig/network-scripts/ifcfg-* files can differ. There can be some important line like missing or presenting HWADDR entry (I don't have any. I test on veth device type with a dynamic hardware address.)

Please also note that versions you specified are not the latest in the EUS channel. E.g kernel is already at 2.6.32-358.41.1.el6. So my and your environment can differ in other components.

Because NetworkManager has been excluded, I suspect initscripts. udev interprets /lib/udev/rules.d/60-net.rules which runs /etc/sysconfig/network-scripts/net.hotplug which calls get_hwaddr() function defined in /etc/sysconfig/network-scripts/network-functions.

Obviously the VLAN and underlying Ethernet interface share the same hardware address. So some of that scripts can get confused and it will restart the underlying Ethernet interface configuration (eth1:1 in your case) which causes resetting the addresses to the default configured values.

Therefore I reassign this bug report to initscripts component.

Comment 10 Terry Bowling 2014-05-30 19:33:01 UTC
I have confirmed in my 6.4 EUS guest that HOTPLUG=no does not help or prevent the eth1:1 device from being reinitialized when vconfig executes.

# rpm -q kernel initscripts ip vconfig
kernel-2.6.32-358.41.1.el6.x86_64
initscripts-9.03.38-1.el6_4.3.x86_64
package ip is not installed
vconfig-1.9-8.1.el6.x86_64


Customer observed the following:

> After that, application (with VLAN need) is brought up, in code, something like 
> below code will cause eth0:1/eth1:1 IP change again which is reported to RH.
                                                                                     
>   if_request.cmd = ADD_VLAN_CMD;                                                                                
>   if (ioctl(fd, SIOCSIFVLAN, &if_request) < 0) {

This matches the assessment by GSS in cmt 6  and cmt 7, hinting at the same area.

Comment 11 Terry Bowling 2014-05-30 19:42:57 UTC
opening this BZ back up to be public for customer visibility as it was originally public.

Comment 12 Lukáš Nykrýn 2014-06-03 13:57:50 UTC
Hmm I am also unable to reproduce your issue.

[root@localhost ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE="eth0"
BOOTPROTO="none"
HWADDR="52:54:00:B7:B7:5A"
IPADDR=192.168.122.111
NETMASK=255.255.255.0
NM_CONTROLLED="no"
ONBOOT="yes"
TYPE="Ethernet"
[root@localhost ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0:0
DEVICE="eth0:0"
BOOTPROTO="none"
HWADDR="52:54:00:B7:B7:5A"
IPADDR=192.168.122.112
NETMASK=255.255.255.0
NM_CONTROLLED="no"
ONPARENT="yes"
TYPE="Ethernet"
[root@localhost ~]# ip addr del 192.168.122.112/32 dev eth0:0
[root@localhost ~]# ip addr add 192.168.122.113/32  label 'eth0:0' dev eth0
[root@localhost ~]# ip addr show dev eth0:0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 52:54:00:b7:b7:5a brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.111/24 brd 192.168.122.255 scope global eth0
    inet 192.168.122.113/32 scope global eth0:0
    inet6 fe80::5054:ff:feb7:b75a/64 scope link 
       valid_lft forever preferred_lft forever
[root@localhost ~]# modprobe 8021q
[root@localhost ~]# ip link add link eth0 name eth0.3999 type vlan id 3999
[root@localhost ~]# ip addr show dev eth0:0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 52:54:00:b7:b7:5a brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.111/24 brd 192.168.122.255 scope global eth0
    inet 192.168.122.113/32 scope global eth0:0
    inet6 fe80::5054:ff:feb7:b75a/64 scope link 
       valid_lft forever preferred_lft forever

Comment 13 Terry Bowling 2014-06-03 21:09:58 UTC
I have configured the following reproducer.

Note that HOTPLUG=no DOES seem to resolve this if put in the parent/physical ifcfg-eth1 config file.

However, it is still seen as a worrisome bug that this is necessary and that enabling hotplugging makes if very dangerous to add vlan aliases on the fly.


** REPRODUCER **
ssh root@cisco-b200m1-01.gsslab.rdu2.redhat.com
pass = linux123


[root@rhel64eus ~]# rpm -q udev initscripts vconfig kernel
udev-147-2.46.el6_4.4.x86_64
initscripts-9.03.38-1.el6_4.3.x86_64
vconfig-1.9-8.1.el6.x86_64
kernel-2.6.32-358.el6.x86_64
kernel-2.6.32-358.41.1.el6.x86_64


This does not help:

	echo "1" > /proc/sys/net/ipv4/conf/default/promote_secondaries 
	echo "1" > /proc/sys/net/ipv4/conf/all/promote_secondaries 
	HOTPLUG=no   set in ifcfg-eth1:1

yum --releasever=6.4 update -y

# cat /etc/sysconfig/network-scripts/ifcfg-eth1:1
DEVICE=eth1:1
ONPARENT=yes
IPADDR=192.168.99.99
NETMASK=255.255.255.0
HOTPLUG=no

Startover test:
	ifdown eth1
	vconfig rem eth1.3999
 	ip addr show

Bring up eth1:1, ONPARENT=yes

	ifup eth1


Verify interfaces DEFAULT IPs:

	ip addr show

	2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
	    inet 10.10.177.77/21 brd 10.10.183.255 scope global eth1
->	    inet 192.168.99.99/24 brd 192.168.99.255 scope global eth1:1

Override eth1:1 to 192.168.20.20

	ip addr add 192.168.20.20/24 label 'eth1:1' dev eth1
	ip addr del 192.168.99.99/24 dev eth1:1
	ip addr show

	2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
	    inet 192.168.10.10/24 brd 10.10.183.255 scope global eth1
->	    inet 192.168.20.20/24 scope global eth1:1


Add vlan 3999 interface to eth1:
	modprobe 8021q
	vconfig add eth1 3999

	Added VLAN with VID == 3999 to IF -:eth1:-

Verify and see that eth1:1 was changed back to the default ip in ifcfg-eth1:1 (10.8.1.1)

	ip addr show 

	2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
	    inet 192.168.10.10/24 brd 192.168.10.255 scope global eth1
->	    inet 192.168.99.99/24 brd 192.168.99.255 scope global eth1:1
                         ^^^^^
reverted back to default specified in ifcfg-eth1:1

Same problem if I use ip link command instead of vconfig

	ip link add link eth1 name eth1.3999 type vlan id 3999


If ONPARENT=no is used, eth1:1 IS DOWNED/OFFLINED!!!!

Comment 14 Lukáš Nykrýn 2014-06-05 08:07:38 UTC
Created attachment 902443 [details]
hotplug patch

So the issue is that if we add a vlan, udev detects that and calls hotplug script. This vlan has the same HWADDR as the regular eth1 device, so the hotplug calls ifup on eth1.

We could fix that (see attached patch), by ignoring virtual devices in hotplug script, but I am afraid it could break some weird use-cases of other customers.

My personal opinion is that we should recommend customer to use HOTPLUG=no.

Comment 15 Lukáš Nykrýn 2014-06-05 12:33:29 UTC
Previous patch was not a good idea. Maybe we should just ignore the event if the source is a vlan.

diff --git a/sysconfig/network-scripts/net.hotplug b/sysconfig/network-scripts/net.hotplug
index 3618196..76195b7 100755
--- a/sysconfig/network-scripts/net.hotplug
+++ b/sysconfig/network-scripts/net.hotplug
@@ -24,6 +24,11 @@ add|register)
            ;;
        # interfaces that are registered then brought up
        *)
+
+            if [ -e /proc/net/vlan/${INTERFACE} ]; then
+                exit 0
+            fi
+
            export IN_HOTPLUG=1
            if [ -x /sbin/ifup ]; then
                addr=$(get_hwaddr ${INTERFACE})

Comment 19 Terry Bowling 2014-06-13 13:47:53 UTC
I have tested this with the reproducer as described in cmt #13.  Seems to work perfectly with both ONPARENT=yes|no.

HOTPLUG=  is not needed at all, so this should be very good for all our customers.

I have shared this with my customer and am waiting on them to test and provide feedback.

I think we should consider this for 6.5.z as it could have negative impacts to entire customer base.

I am submitting a formal request for 6.4 EUS on behalf of my customer.  I assume this would trigger 6.5.z as well.

Comment 24 errata-xmlrpc 2014-10-14 06:28:35 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2014-1448.html


Note You need to log in before you can comment on or make changes to this bug.