Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1116314 - netcf can not generate all-ones netmask on a interface
netcf can not generate all-ones netmask on a interface
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: netcf (Show other bugs)
6.6
x86_64 Linux
medium Severity medium
: rc
: ---
Assigned To: Laine Stump
Virtualization Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2014-07-04 04:34 EDT by Hu Jianwei
Modified: 2015-07-22 02:26 EDT (History)
5 users (show)

See Also:
Fixed In Version: netcf-0.2.4-2.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-07-22 02:26:05 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:1307 normal SHIPPED_LIVE netcf bug fix update 2015-07-20 13:53:43 EDT

  None (edit)
Description Hu Jianwei 2014-07-04 04:34:53 EDT
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 01:09:52 EDT
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 00:41:54 EST
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 01:19:15 EST
(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 02:26:05 EDT
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.