Bug 1116314 - netcf can not generate all-ones netmask on a interface
Summary: netcf can not generate all-ones netmask on a interface
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: netcf
Version: 6.6
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Laine Stump
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-04 08:34 UTC by Hu Jianwei
Modified: 2015-07-22 06:26 UTC (History)
5 users (show)

Fixed In Version: netcf-0.2.4-2.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-07-22 06:26:05 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:1307 normal SHIPPED_LIVE netcf bug fix update 2015-07-20 17:53:43 UTC

Description Hu Jianwei 2014-07-04 08:34:53 UTC
Description of problem:
netcf can not generate all-ones netmask on a interface

Version-Release number of selected component (if applicable):
libvirt-0.10.2-40.el6.x86_64
netcf-0.2.4-1.el6.x86_64

How reproducible:
100%

Steps to Reproduce:
[root@rhel6 iface]# cat eth1.xml
<interface type='ethernet' name='eth1'>
  <start mode='onboot'/>
  <mac address='00:1b:21:27:4e:ce'/>
  <protocol family='ipv4'>
    <ip address='192.168.177.1' prefix='32'/>
  </protocol>
</interface>

[root@rhel6 iface]# ncftool define eth1.xml
Defined interface eth1
[root@rhel6 iface]# ncftool dumpxml eth1
<?xml version="1.0"?>
<interface type="ethernet" name="eth1">
  <start mode="onboot"/>
  <mac address="00:1b:21:27:4e:ce"/>
  <protocol family="ipv4">
    <ip address="192.168.177.1" prefix="0"/>
  </protocol>
</interface>

[root@rhel6 iface]# cat /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
HWADDR=00:1b:21:27:4e:ce
ONBOOT=yes
BOOTPROTO=none
IPADDR=192.168.177.1
NETMASK=0.0.0.0

Using libvirt commands:
[root@rhel6 iface]# cat eth1.xml
<interface type='ethernet' name='eth1'>
  <start mode='onboot'/>
  <mac address='00:1b:21:27:4e:ce'/>
  <protocol family='ipv4'>
    <ip address='192.168.177.1' prefix='32'/>
  </protocol>
</interface>

[root@rhel6 iface]# virsh iface-define eth1.xml
Interface eth1 defined from eth1.xml

[root@rhel6 iface]# virsh iface-dumpxml eth1
<interface type='ethernet' name='eth1'>
  <mac address='00:1b:21:27:4e:ce'/>
  <protocol family='ipv4'>
    <ip address='192.168.177.1'/>
  </protocol>
  <protocol family='ipv6'>
    <ip address='fe80::21b:21ff:fe27:4ece' prefix='64'/>
  </protocol>
</interface>

[root@rhel6 iface]# cat /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
HWADDR=00:1b:21:27:4e:ce
ONBOOT=yes
BOOTPROTO=none
IPADDR=192.168.177.1
NETMASK=0.0.0.0

Actual results:
As shown above steps, the netmask 0.0.0.0 instead of 255.255.255.255 in ifcfg-eth1.

Expected results:
The netmask of interface should be 255.255.255.255 rather than 0.0.0.0, both are different subnet(subnet zero and the all-ones subnet).

[root@rhel6 netcf-0.2.4]# ipcalc -m 192.168.177.1/32
NETMASK=255.255.255.255
[root@rhel6 netcf-0.2.4]# ipcalc -m 192.168.177.1/0
NETMASK=0.0.0.0

If netcf/libvirt does not support such netmask/prefix, please throw a clear warning message.

Comment 3 Laine Stump 2014-08-20 05:09:52 UTC
A fix for this has been pushed upstream:

commit 09f03a2aa1ce5409536a72bd4b480fb2eae3dfac
Author: Laine Stump <laine@laine.org>
Date:   Tue Aug 19 23:14:26 2014 -0400

    Fix netmask for prefix == 32
    
    If an interface was defines with a network prefix of 32 (could be used
    for a point-to-point link), instead of translating into a netmask of
    255.255.255.255, it would end up being 0.0.0.0. This behavior was
    caused by the function ipcalc_netmask() assuming that
    ~(0xffffffffu >> 32) would be 0xffffffffu, when in fact the result of
    shifting right a 32 bit number by 32 positions is undefined. As it
    happens, in the case of the code generated by gcc, the result of the
    above is 0, when it should in fact be 0xffffffffu.
    
    The safe way to deal with this is to simply special-case prefix == 32.

Comment 8 Hu Jianwei 2015-03-05 05:41:54 UTC
The bug can not reproduce from netcf layer,but using virsh iface-* still can reproduce it.

[root@longevity netcf]# rpm -q netcf
netcf-0.2.4-2.el6.x86_64

[root@longevity netcf]# cat eth8.xml
<interface type='ethernet' name='eth8'>
<start mode='onboot'/>
<mac address='00:1b:21:27:4e:88'/>
<protocol family='ipv4'>
<ip address='192.168.188.1' prefix='32'/>
</protocol>
</interface>

[root@longevity netcf]# cat /etc/sysconfig/network-scripts/ifcfg-eth8
DEVICE=eth8
HWADDR=00:1b:21:27:4e:88
ONBOOT=yes
BOOTPROTO=none
IPADDR=192.168.188.1
NETMASK=255.255.255.255

[root@longevity netcf]# ncftool dumpxml eth8
<?xml version="1.0"?>
<interface type="ethernet" name="eth8">
  <start mode="onboot"/>
  <mac address="00:1b:21:27:4e:88"/>
  <protocol family="ipv4">
    <ip address="192.168.188.1" prefix="32"/>
  </protocol>
</interface>

Using virsh iface-* cmds
[root@longevity netcf]# rpm -q libvirt netcf-libs
libvirt-0.10.2-49.el6.x86_64
netcf-libs-0.2.4-2.el6.x86_64

[root@longevity netcf]# cat eth8.xml 
<interface type='ethernet' name='eth8'>
<start mode='onboot'/>
<mac address='00:1b:21:27:4e:88'/>
<protocol family='ipv4'>
<ip address='192.168.188.1' prefix='32'/>
</protocol>
</interface>
[root@longevity netcf]# virsh iface-define eth8.xml 
Interface eth8 defined from eth8.xml

[root@longevity netcf]# virsh iface-dumpxml eth8
<interface type='ethernet' name='eth8'>
  <start mode='onboot'/>
  <mac address='00:1b:21:27:4e:88'/>
  <protocol family='ipv4'>
    <ip address='192.168.188.1'/>
  </protocol>
</interface>

[root@longevity netcf]# cat /etc/sysconfig/network-scripts/ifcfg-eth8
DEVICE=eth8
HWADDR=00:1b:21:27:4e:88
ONBOOT=yes
BOOTPROTO=none
IPADDR=192.168.188.1
NETMASK=0.0.0.0

Please help me check it, thanks.

Comment 9 Hu Jianwei 2015-03-05 06:19:15 UTC
(In reply to Hu Jianwei from comment #8)
> Using virsh iface-* cmds
> [root@longevity netcf]# rpm -q libvirt netcf-libs
> libvirt-0.10.2-49.el6.x86_64
> netcf-libs-0.2.4-2.el6.x86_64
> 
> [root@longevity netcf]# cat eth8.xml 
> <interface type='ethernet' name='eth8'>
> <start mode='onboot'/>
> <mac address='00:1b:21:27:4e:88'/>
> <protocol family='ipv4'>
> <ip address='192.168.188.1' prefix='32'/>
> </protocol>
> </interface>
> [root@longevity netcf]# virsh iface-define eth8.xml 
> Interface eth8 defined from eth8.xml
> 
> [root@longevity netcf]# virsh iface-dumpxml eth8
> <interface type='ethernet' name='eth8'>
>   <start mode='onboot'/>
>   <mac address='00:1b:21:27:4e:88'/>
>   <protocol family='ipv4'>
>     <ip address='192.168.188.1'/>
>   </protocol>
> </interface>
> 
> [root@longevity netcf]# cat /etc/sysconfig/network-scripts/ifcfg-eth8
> DEVICE=eth8
> HWADDR=00:1b:21:27:4e:88
> ONBOOT=yes
> BOOTPROTO=none
> IPADDR=192.168.188.1
> NETMASK=0.0.0.0
> 
> Please help me check it, thanks.

Sorry, I made a mistake just now, should restart libvirtd after updating netcf packages.

[root@longevity netcf-0.2.4]# service libvirtd restart
Stopping libvirtd daemon:                                  [  OK  ]
Starting libvirtd daemon:                                  [  OK  ]

[root@longevity netcf]# virsh iface-define eth8.xml 
Interface eth8 defined from eth8.xml

[root@longevity netcf]# virsh iface-dumpxml eth8
<interface type='ethernet' name='eth8'>
  <start mode='onboot'/>
  <mac address='00:1b:21:27:4e:88'/>
  <protocol family='ipv4'>
    <ip address='192.168.188.1' prefix='32'/>
  </protocol>
</interface>

[root@longevity netcf]# cat /etc/sysconfig/network-scripts/ifcfg-eth8 
DEVICE=eth8
HWADDR=00:1b:21:27:4e:88
ONBOOT=yes
BOOTPROTO=none
IPADDR=192.168.188.1
NETMASK=255.255.255.255

The bug has been fixed, changed to Verified.

Comment 12 errata-xmlrpc 2015-07-22 06:26:05 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.

https://rhn.redhat.com/errata/RHBA-2015-1307.html


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