View Issue Details

IDProjectCategoryView StatusLast Update
0015652CentOS-7NetworkManagerpublic2018-12-30 08:23
Reportertez 
PrioritynormalSeverityminorReproducibilityalways
Status newResolutionopen 
Product Version7.6.1810 
Target VersionFixed in Version 
Summary0015652: NetworkManager doesn't want to configure Ethernet interfaces with /31 IPv4 netmask
DescriptionNetworkManager is unable to bring an IPv4 interface up that has been configured with a /31 netmask but if you forcibly disable NetworkManager, the interface can then be brought up and send/receive IPv4 traffic.

Reporting the bug against NetworkManager as it is unable to bring the interface up but the fallback initscripts are able to do so.
Steps To ReproduceConfigure any spare Ethernet interface with an IPv4 address and a /31 netmask:

The one I used:

DEVICE=eth1
ONBOOT=yes
HWADDR=1E:EC:76:65:2F:C3
TYPE=Ethernet
BOOTPROTO=none
IPADDR=192.0.2.2
GATEWAY=192.0.2.3
NETMASK=255.255.255.254
IPV6ADDR_SECONDARIES=""
MTU=1480
DNS1=2001:4860:4860::8888
DNS2=2001:4860:4860::8844

[root@tvhc-nat64-gw1 network-scripts]# systemctl status -l NetworkManager
● NetworkManager.service - Network Manager
   Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2018-12-29 20:09:19 GMT; 38s ago
     Docs: man:NetworkManager(8)
 Main PID: 4085 (NetworkManager)
   CGroup: /system.slice/NetworkManager.service
           └─4085 /usr/sbin/NetworkManager --no-daemon

Dec 29 20:09:21 tvhc-nat64-gw1.example.com NetworkManager[4085]: <info> [1546114161.0268] manager: NetworkManager state is now DISCONNECTED
Dec 29 20:09:21 tvhc-nat64-gw1.example.com NetworkManager[4085]: <warn> [1546114161.0275] device (eth1): Activation: failed for connection 'System eth1'
Dec 29 20:09:21 tvhc-nat64-gw1.example.com NetworkManager[4085]: <info> [1546114161.0281] device (eth1): state change: failed -> disconnected (reason 'none', sys-iface-state: 'managed')
Dec 29 20:09:50 tvhc-nat64-gw1.example.com NetworkManager[4085]: <info> [1546114190.0141] device (eth0): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'assume')
Dec 29 20:09:50 tvhc-nat64-gw1.example.com NetworkManager[4085]: <info> [1546114190.0158] device (eth0): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'assume')
Dec 29 20:09:50 tvhc-nat64-gw1.example.com NetworkManager[4085]: <info> [1546114190.0163] device (eth0): state change: secondaries -> activated (reason 'none', sys-iface-state: 'assume')
Dec 29 20:09:50 tvhc-nat64-gw1.example.com NetworkManager[4085]: <info> [1546114190.0168] manager: NetworkManager state is now CONNECTED_SITE
Dec 29 20:09:50 tvhc-nat64-gw1.example.com NetworkManager[4085]: <info> [1546114190.0596] device (eth0): Activation: successful, device activated.
Dec 29 20:09:50 tvhc-nat64-gw1.example.com NetworkManager[4085]: <info> [1546114190.0610] manager: NetworkManager state is now CONNECTED_GLOBAL
Dec 29 20:09:50 tvhc-nat64-gw1.example.com NetworkManager[4085]: <info> [1546114190.0620] manager: startup complete
[root@tvhc-nat64-gw1 network-scripts]# ifup eth1
Error: Connection activation failed: IP configuration could not be reserved (no available address, timeout, etc.)
[root@tvhc-nat64-gw1 network-scripts]# ip addr ls dev eth1
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1480 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 1e:ec:76:65:2f:c3 brd ff:ff:ff:ff:ff:ff
[root@tvhc-nat64-gw1 network-scripts]# systemctl stop NetworkManager
[root@tvhc-nat64-gw1 network-scripts]# ifup eth1
[root@tvhc-nat64-gw1 network-scripts]# ip addr ls dev eth1
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1480 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 1e:ec:76:65:2f:c3 brd ff:ff:ff:ff:ff:ff
    inet 192.0.2.2/31 brd 255.255.255.255 scope global eth1
       valid_lft forever preferred_lft forever
[root@tvhc-nat64-gw1 network-scripts]# cat ifcfg-eth1
DEVICE=eth1
ONBOOT=yes
HWADDR=1E:EC:76:65:2F:C3
TYPE=Ethernet
BOOTPROTO=none
IPADDR=192.0.2.2
GATEWAY=192.0.2.3
NETMASK=255.255.255.254
IPV6ADDR_SECONDARIES=""
MTU=1480
DNS1=2001:4860:4860::8888
DNS2=2001:4860:4860::8844
[root@tvhc-nat64-gw1 network-scripts]# ping -c 4 192.0.2.3
PING 192.0.2.3 (192.0.2.3) 56(84) bytes of data.
64 bytes from 192.0.2.3: icmp_seq=1 ttl=64 time=1.43 ms
64 bytes from 192.0.2.3: icmp_seq=2 ttl=64 time=1.16 ms
64 bytes from 192.0.2.3: icmp_seq=3 ttl=64 time=1.23 ms
64 bytes from 192.0.2.3: icmp_seq=4 ttl=64 time=1.59 ms

--- 192.0.2.3 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 1.169/1.359/1.598/0.171 ms
[root@tvhc-nat64-gw1 network-scripts]#
TagsNo tags attached.
abrt_hash
URL

Activities

SiriusP2324

SiriusP2324

2018-12-30 04:50

reporter   ~0033476

This is not really a bug. Apparently, NetworkManager automatically calculates the broadcast address, which doesn't work with a /31. Are you sure you want to use a /31? Those are typically reserved for point-to-point links, used by routers. Using a /31, NetworkManager will assign the peer-end IP as the broadcast IP, and you wouldn't be able to communicate with the other side of the link.

Since and 'Ethernet Network' is a broadcast network, and Ethernet Interface cannot be configured without a broadcast IP address. Here is an article that provide potential workarounds (https://1138blog.wordpress.com/2017/09/19/setting-up-31-interfaces-and-bgp-on-a-centos-machine/).

RFC-3021 permits /31 for Point-to-point links! Conceptually, a 31-bit mask isn't valid on a broadcast network.
tez

tez

2018-12-30 08:23

reporter   ~0033478

Yes, this is really a bug.

Given the well-publicized shortage of routable IPv4 addresses, RFC3021 is one of many tools that network folk are using to try and eke as much useful life out of their respective IPv4 assignments as possible.

Ethernet is not a broadcast network; it is a technology which supports broadcast - both directed and non-directed broadcast - sure, you lose the ability to run broadcast-dependent protocols across a /31 link but that is already warned about (and documented) in RFC3021.

In a point-to-point Ethernet configuration, a packet sent by Host A will always be received by Host B and vice-versa.

With regards to Ethernet not being configured without a broadcast IP address, yes, you are absolutely right but this particular issue was fixed in RHEL 6.3 by the upstream vendor as documented in https://bugzilla.redhat.com/show_bug.cgi?id=997271

The use of NM_CONTROLLED=no as suggested by your provided URL is indeed a valid workaround and one which does work; so, disabling NetworkManager across the board might be slightly overkill but as I believe that it is the upstream vendors' eventual intention to deprecate and discontinue support of network initscripts in favour of NetworkManager, it is better that there is as much compatibility between those two software components as possible in order to facilitate easier upgrades/migration in the future.

I do realize that CentOS aims to be 'bug-for-bug' compatible with the upstream vendor's published binaries so I do not expect CentOS to make any changes to fix NetworkManager in response to this bug but if you do not wish to raise this as a bug in the upstream vendors' own Bugzilla instance, I am quite happy to do to that myself.

Issue History

Date Modified Username Field Change
2018-12-29 20:29 tez New Issue
2018-12-30 04:50 SiriusP2324 Note Added: 0033476
2018-12-30 08:23 tez Note Added: 0033478