Bug 980785 - External network not reachable after update to NetworkManager-0.9.8.2-4.fc19.x86_64
External network not reachable after update to NetworkManager-0.9.8.2-4.fc19....
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
19
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-03 04:44 EDT by Cristian Sava
Modified: 2015-02-17 10:48 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: Consequence: Result:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-02-17 10:48:44 EST
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)
Tests to debug the reported problem (18.49 KB, text/plain)
2013-07-04 09:57 EDT, Cristian Sava
no flags Details

  None (edit)
Description Cristian Sava 2013-07-03 04:44:28 EDT
Description of problem:


Afeter upgrading to NetworkManager-0.9.8.2-4.fc19.x86_64 my server external network is not accessible.

The external network is not reachable anymore but the internal network is ok if NM is enabled and working.
The shown setup does not work with network service anymore.

Version-Release number of selected component (if applicable):
NetworkManager-0.9.8.2-4.fc19.x86_64

How reproducible:

A server with two NICs (on-board and attached).
HW: ASRock H67M-GE + I3-2120 + 8GB + 1TB (hdd, sata)

[root@physics network-scripts]# cat ifcfg-enp4s0
IPV6_PEERDNS="yes"
IPV6INIT="yes"
UUID="b43c0128-ec02-4793-98c9-f396fb9438d2"
IPADDR1="192.168.1.1"
IPADDR0="172.16.0.1"
PREFIX1="24"
PREFIX0="16"
DEFROUTE="yes"
IPV4_FAILURE_FATAL="yes"
HWADDR="64:70:02:14:43:EF"
BOOTPROTO="none"
IPV6_DEFROUTE="yes"
IPV6_AUTOCONF="yes"
IPV6_FAILURE_FATAL="no"
IPV6_PEERROUTES="yes"
TYPE="Ethernet"
ONBOOT="yes"
NAME="enp4s0"
[root@physics network-scripts]# cat ifcfg-enp5s0
TYPE=Ethernet
BOOTPROTO=none
DEFROUTE=yes
IPV4_FAILURE_FATAL=yes
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
NAME=enp5s0
UUID=fc903246-75fa-4680-86f8-b5132fc891c5
ONBOOT=yes
IPADDR0=193.x.y.130
PREFIX0=26
GATEWAY0=193.x.y.129
DNS1=193.x.y.254
DOMAIN=central.ucv.ro
IPADDR1=193.x.y.162
PREFIX1=26
IPADDR2=193.x.y.163
PREFIX2=26
HWADDR=00:25:22:F9:71:3D
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes

[root@physics ~]# route
Kernel IP routing table
Destination  Gateway         Genmask      Flags Metric Ref Use Iface
default      g129.central.uc 0.0.0.0         UG  0      0   0 p5p1
link-local     *             255.255.0.0     U   1002   0   0 p4p1
link-local     *             255.255.0.0     U   1003   0   0 p5p1
172.16.0.0     *             255.255.0.0     U   1      0   0 p4p1
192.168.1.0    *             255.255.255.0   U   0      0   0 p4p1
193.x.y.128    *             255.255.255.192 U   1      0   0 p5p1

[root@s194 sysconfig]# cat iptables
# Custom file edited on 02-Jul-2013
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j ACCEPT
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT
# Completed on 2013-07-02 11:48
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A PREROUTING --dst 193.x.y.162 -p tcp -j DNAT --to 192.168.1.73
-A OUTPUT --dst 193.x.y.162 -p tcp -j DNAT --to 192.168.1.73
-A PREROUTING --dst 193.x.y.163 -p tcp -j DNAT --to 192.168.1.200
-A OUTPUT --dst 193.x.y.163 -p tcp -j DNAT --to 192.168.1.200
-A POSTROUTING -s 192.168.1.0/24 -p tcp --dst 192.168.1.73 --dport 22 -j SNAT --to 192.168.1.1
-A POSTROUTING -s 192.168.1.0/24 -o p5p1 -j SNAT --to-source 193.x.y.130
-A POSTROUTING -s 172.16.0.0/16 -o p5p1 -j SNAT --to-source 193.x.y.130
COMMIT


Actual results:

With F19 install (no updates) it is the same with NM or with network service.

1) Why "route" shows iface=p4p1, p5p1 instead enp4s0, enp5s0 ?
2) Why "ifconfig" does show only the IPADDR0 without aliases?
3) All is working as expected when 192.168.1.73 is on-line. If ...73 not on-line, the address 193.x.y.162 is assigned to the the server, it responds to "ping 193.x.y.162" but it should be unreachable (or something equivalent) because 192.168.1.73 is off.
Similar for 193.x.y.163 .


Expected results:


Additional info:

From /var/log/messages when starting NM:

Jul  3 11:02:51 physics rsyslogd: [origin software="rsyslogd" swVersion="7.2.6" x-pid="306" x-info="http://www.rsyslog.com"] rsyslogd was HUPed
Jul  3 11:03:44 physics systemd[1]: Stopping Network Manager...
Jul  3 11:03:44 physics NetworkManager[1704]: <info> caught signal 15, shutting down normally.
Jul  3 11:03:44 physics NetworkManager[1704]: <info> exiting (success)
Jul  3 11:03:44 physics systemd[1]: Starting Network Manager...
Jul  3 11:03:44 physics NetworkManager[1924]: <info> NetworkManager (version 0.9.8.2-4.fc19) is starting...
Jul  3 11:03:44 physics NetworkManager[1924]: <info> Read config file /etc/NetworkManager/NetworkManager.conf
Jul  3 11:03:44 physics NetworkManager[1924]: <info> WEXT support is enabled
Jul  3 11:03:44 physics NetworkManager[1924]:    ifcfg-rh: Acquired D-Bus service com.redhat.ifcfgrh1
Jul  3 11:03:44 physics NetworkManager[1924]: <info> Loaded plugin ifcfg-rh: (c) 2007 - 2010 Red Hat, Inc.  To report bugs please use the NetworkManager mailing list.
Jul  3 11:03:44 physics NetworkManager[1924]: <info> Loaded plugin keyfile: (c) 2007 - 2010 Red Hat, Inc.  To report bugs please use the NetworkManager mailing list.
Jul  3 11:03:44 physics NetworkManager[1924]:    ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-lo ...
Jul  3 11:03:44 physics NetworkManager[1924]:    ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-enp5s0 ...
Jul  3 11:03:44 physics NetworkManager[1924]:    ifcfg-rh:     read connection 'enp5s0'
Jul  3 11:03:44 physics NetworkManager[1924]:    ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-enp4s0 ...
Jul  3 11:03:44 physics NetworkManager[1924]:    ifcfg-rh:     read connection 'enp4s0'
Jul  3 11:03:44 physics NetworkManager[1924]: <info> monitoring kernel firmware directory '/lib/firmware'.
Jul  3 11:03:44 physics NetworkManager[1924]: <info> WiFi enabled by radio killswitch; enabled by state file
Jul  3 11:03:44 physics NetworkManager[1924]: <info> WWAN enabled by radio killswitch; enabled by state file
Jul  3 11:03:44 physics NetworkManager[1924]: <info> WiMAX enabled by radio killswitch; enabled by state file
Jul  3 11:03:44 physics NetworkManager[1924]: <info> Networking is enabled by state file
Jul  3 11:03:44 physics NetworkManager[1924]: <warn> failed to allocate link cache: (-10) Operation not supported
Jul  3 11:03:44 physics NetworkManager[1924]: <info> (p4p1): carrier is ON
Jul  3 11:03:44 physics NetworkManager[1924]: <info> (p4p1): new Ethernet device (driver: 'r8169' ifindex: 2)
Jul  3 11:03:44 physics NetworkManager[1924]: <info> (p4p1): exported as /org/freedesktop/NetworkManager/Devices/0
Jul  3 11:03:44 physics NetworkManager[1924]: <info> (p4p1): device state change: unmanaged -> unavailable (reason 'connection-assumed') [10 20 41]
Jul  3 11:03:44 physics NetworkManager[1924]: <info> (p4p1): preparing device.
Jul  3 11:03:44 physics NetworkManager[1924]: <info> Activation (p4p1) starting connection 'enp4s0'
Jul  3 11:03:44 physics NetworkManager[1924]: (nm-device.c:3894):nm_device_activate: runtime check failed: (priv->state == NM_DEVICE_STATE_DISCONNECTED)
Jul  3 11:03:44 physics NetworkManager[1924]: <info> (p4p1): device state change: unavailable -> ip-config (reason 'none') [20 70 0]
Jul  3 11:03:44 physics NetworkManager[1924]: <info> Activation (p4p1) Stage 3 of 5 (IP Configure Start) scheduled.
Jul  3 11:03:44 physics NetworkManager[1924]: <warn> failed to allocate link cache: (-10) Operation not supported
Jul  3 11:03:44 physics NetworkManager[1924]: <info> (p5p1): carrier is ON
Jul  3 11:03:44 physics NetworkManager[1924]: <info> (p5p1): new Ethernet device (driver: 'r8169' ifindex: 3)
Jul  3 11:03:44 physics NetworkManager[1924]: <info> (p5p1): exported as /org/freedesktop/NetworkManager/Devices/1
Jul  3 11:03:44 physics NetworkManager[1924]: <info> (p5p1): device state change: unmanaged -> unavailable (reason 'connection-assumed') [10 20 41]
Jul  3 11:03:44 physics NetworkManager[1924]: <info> (p5p1): preparing device.
Jul  3 11:03:44 physics NetworkManager[1924]: <info> Activation (p5p1) starting connection 'enp5s0'
Jul  3 11:03:44 physics NetworkManager[1924]: (nm-device.c:3894):nm_device_activate: runtime check failed: (priv->state == NM_DEVICE_STATE_DISCONNECTED)
Jul  3 11:03:44 physics NetworkManager[1924]: <info> (p5p1): device state change: unavailable -> ip-config (reason 'none') [20 70 0]
Jul  3 11:03:44 physics NetworkManager[1924]: <info> Activation (p5p1) Stage 3 of 5 (IP Configure Start) scheduled.
Jul  3 11:03:44 physics NetworkManager[1924]: <warn> /sys/devices/virtual/net/lo: couldn't determine device driver; ignoring...
Jul  3 11:03:44 physics NetworkManager[1924]: <warn> /sys/devices/virtual/net/lo: couldn't determine device driver; ignoring...
Jul  3 11:03:44 physics NetworkManager[1924]: <info> Activation (p4p1) Stage 3 of 5 (IP Configure Start) started...
Jul  3 11:03:44 physics NetworkManager[1924]: <info> Activation (p4p1) Stage 5 of 5 (IPv4 Configure Commit) scheduled...
Jul  3 11:03:44 physics NetworkManager[1924]: <info> Activation (p4p1) Beginning IP6 addrconf.
Jul  3 11:03:44 physics avahi-daemon[303]: Withdrawing address record for fe80::6670:2ff:fe14:43ef on p4p1.
Jul  3 11:03:44 physics NetworkManager[1924]: <info> Activation (p4p1) Stage 3 of 5 (IP Configure Start) complete.
Jul  3 11:03:44 physics NetworkManager[1924]: <info> Activation (p5p1) Stage 3 of 5 (IP Configure Start) started...
Jul  3 11:03:44 physics NetworkManager[1924]: <info> Activation (p5p1) Stage 5 of 5 (IPv4 Configure Commit) scheduled...
Jul  3 11:03:44 physics NetworkManager[1924]: <info> Activation (p5p1) Beginning IP6 addrconf.
Jul  3 11:03:44 physics avahi-daemon[303]: Withdrawing address record for fe80::225:22ff:fef9:713d on p5p1.
Jul  3 11:03:44 physics NetworkManager[1924]: <info> Activation (p5p1) Stage 3 of 5 (IP Configure Start) complete.
Jul  3 11:03:44 physics NetworkManager[1924]: <warn> error monitoring device for netlink events: error processing netlink message: Object busy
Jul  3 11:03:44 physics NetworkManager[1924]: <info> Activation (p4p1) Stage 5 of 5 (IPv4 Commit) started...
Jul  3 11:03:44 physics NetworkManager[1924]: <info> (p4p1): device state change: ip-config -> secondaries (reason 'none') [70 90 0]
Jul  3 11:03:44 physics NetworkManager[1924]: <info> Activation (p4p1) Stage 5 of 5 (IPv4 Commit) complete.
Jul  3 11:03:44 physics NetworkManager[1924]: <info> Activation (p5p1) Stage 5 of 5 (IPv4 Commit) started...
Jul  3 11:03:44 physics NetworkManager[1924]: <info> (p5p1): device state change: ip-config -> secondaries (reason 'none') [70 90 0]
Jul  3 11:03:44 physics NetworkManager[1924]: <info> Activation (p5p1) Stage 5 of 5 (IPv4 Commit) complete.
Jul  3 11:03:44 physics NetworkManager[1924]: <info> (p4p1): device state change: secondaries -> activated (reason 'none') [90 100 0]
Jul  3 11:03:44 physics systemd[1]: Started Network Manager.
Jul  3 11:03:44 physics NetworkManager[1924]: <info> Policy set 'enp5s0' (p5p1) as default for IPv4 routing and DNS.
Jul  3 11:03:44 physics NetworkManager[1924]: <info> Activation (p4p1) successful, device activated.
Jul  3 11:03:44 physics NetworkManager[1924]: <info> (p5p1): device state change: secondaries -> activated (reason 'none') [90 100 0]
Jul  3 11:03:44 physics dbus-daemon[314]: dbus[314]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service'
Jul  3 11:03:44 physics dbus-daemon[314]: dbus[314]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.nm-dispatcher.service': Unit dbus-org.freedesktop.nm-dispatcher.service failed to load: No such file or directory. See system logs and 'systemctl status dbus-org.freedesktop.nm-dispatcher.service' for details.
Jul  3 11:03:44 physics dbus[314]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service'
Jul  3 11:03:44 physics dbus[314]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.nm-dispatcher.service': Unit dbus-org.freedesktop.nm-dispatcher.service failed to load: No such file or directory. See system logs and 'systemctl status dbus-org.freedesktop.nm-dispatcher.service' for details.
Jul  3 11:03:44 physics NetworkManager[1924]: <info> Activation (p5p1) successful, device activated.
Jul  3 11:03:44 physics dbus-daemon[314]: dbus[314]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service'
Jul  3 11:03:44 physics dbus-daemon[314]: dbus[314]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.nm-dispatcher.service': Unit dbus-org.freedesktop.nm-dispatcher.service failed to load: No such file or directory. See system logs and 'systemctl status dbus-org.freedesktop.nm-dispatcher.service' for details.
Jul  3 11:03:44 physics dbus[314]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service'
Jul  3 11:03:44 physics NetworkManager[1924]: <warn> Dispatcher failed: (32) Unit dbus-org.freedesktop.nm-dispatcher.service failed to load: No such file or directory. See system logs and 'systemctl status dbus-org.freedesktop.nm-dispatcher.service' for details.
Jul  3 11:03:44 physics dbus[314]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.nm-dispatcher.service': Unit dbus-org.freedesktop.nm-dispatcher.service failed to load: No such file or directory. See system logs and 'systemctl status dbus-org.freedesktop.nm-dispatcher.service' for details.
Jul  3 11:03:44 physics NetworkManager[1924]: <warn> Dispatcher failed: (32) Unit dbus-org.freedesktop.nm-dispatcher.service failed to load: No such file or directory. See system logs and 'systemctl status dbus-org.freedesktop.nm-dispatcher.service' for details.
Jul  3 11:03:45 physics avahi-daemon[303]: Registering new address record for fe80::225:22ff:fef9:713d on p5p1.*.
Jul  3 11:03:46 physics avahi-daemon[303]: Registering new address record for fe80::6670:2ff:fe14:43ef on p4p1.*.
Jul  3 11:03:55 physics NetworkManager[1924]: <warn> error monitoring device for netlink events: error processing netlink message: Object busy
Jul  3 11:04:04 physics NetworkManager[1924]: <info> (p4p1): IP6 addrconf timed out or failed.
Jul  3 11:04:04 physics NetworkManager[1924]: <info> Activation (p4p1) Stage 4 of 5 (IPv6 Configure Timeout) scheduled...
Jul  3 11:04:04 physics NetworkManager[1924]: <info> (p5p1): IP6 addrconf timed out or failed.
Jul  3 11:04:04 physics NetworkManager[1924]: <info> Activation (p5p1) Stage 4 of 5 (IPv6 Configure Timeout) scheduled...
Jul  3 11:04:04 physics NetworkManager[1924]: <info> Activation (p4p1) Stage 4 of 5 (IPv6 Configure Timeout) started...
Jul  3 11:04:04 physics NetworkManager[1924]: <info> Activation (p4p1) Stage 4 of 5 (IPv6 Configure Timeout) complete.
Jul  3 11:04:04 physics NetworkManager[1924]: <info> Activation (p5p1) Stage 4 of 5 (IPv6 Configure Timeout) started...
Jul  3 11:04:04 physics NetworkManager[1924]: <info> Activation (p5p1) Stage 4 of 5 (IPv6 Configure Timeout) complete.
Comment 1 Cristian Sava 2013-07-03 05:14:09 EDT
Mainly, this bug is due to kernel-3.9.8-300.fc19.x86_64 and downgrading to kernel-3.9.5-301.fc19.x86_64 solve the networking accessibility. The other points are still valid.
Comment 2 Cristian Sava 2013-07-04 09:57:18 EDT
Created attachment 768819 [details]
Tests to debug the reported problem

Different tests regarding network and NetworkManager services
Comment 3 Cristian Sava 2013-07-04 10:03:55 EDT
As Adam Williamson suggested biosdevname=0 on the kernel line solve the interface name (as shown in the test case file already attached).
Anyway, this parameter should not be needed if some bug is not present.
Comment 4 Cristian Sava 2013-07-05 07:13:17 EDT
Installing F19 Gnome Desktop in VirtualBox-4.2.14 under Win7_x64:

  route gives p2p1 and we have ifcfg-enp0s3 !!!

[root@localhost ~]# uname -a
Linux localhost.localdomain 3.9.9-301.fc19.x86_64 #1 SMP Thu Jul 4 15:10:36 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
[root@localhost ~]# rpm -q NetworkManager
NetworkManager-0.9.8.2-5.fc19.x86_64
[root@localhost ~]# route
Kernel IP routing table
Destination  Gateway      Genmask        Flags Metric Ref Use Iface
default      193.x.y.193  0.0.0.0         UG    0      0    0 p2p1
193.x.y.192  *            255.255.255.224 U     1      0    0 p2p1
[root@localhost ~]# ls /etc/sysconfig/network-scripts
ifcfg-enp0s3  ifdown-eth   ifdown-post    ifdown-tunnel  ifup-eth   ifup-isdn   ifup-ppp     ifup-wireless
ifcfg-lo      ifdown-ippp  ifdown-ppp     ifup           ifup-ippp  ifup-plip   ifup-routes  init.ipv6-global
ifdown        ifdown-ipv6  ifdown-routes  ifup-aliases   ifup-ipv6  ifup-plusb  ifup-sit     network-functions
ifdown-bnep   ifdown-isdn  ifdown-sit     ifup-bnep      ifup-ipx   ifup-post   ifup-tunnel  network-functions-ipv6
Comment 5 Cristian Sava 2013-07-09 02:39:49 EDT
On installs where iface reported by "route" command is not the same with ifcfg-iface (pxpy instead of enpxsy or ethx) fail2ban will not start.
Does not matter if biosdevname=0 or net.ifnames=0 on the kernel line.
Tested this on real hardware and on VirualBox too.
From /var/log/messages:
fail2ban-client[2804]: ERROR  Directory /var/run/fail2ban exists but not accessible for writing
Fail2ban is ok on any other install.
Comment 6 Jirka Klimes 2013-07-10 03:56:47 EDT
(In reply to Cristian Sava from comment #0)
> With F19 install (no updates) it is the same with NM or with network service.
> 
> 1) Why "route" shows iface=p4p1, p5p1 instead enp4s0, enp5s0 ?
> 2) Why "ifconfig" does show only the IPADDR0 without aliases?
> 3) All is working as expected when 192.168.1.73 is on-line. If ...73 not
> on-line, the address 193.x.y.162 is assigned to the the server, it responds
> to "ping 193.x.y.162" but it should be unreachable (or something equivalent)
> because 192.168.1.73 is off.
> Similar for 193.x.y.163 .
> 
1) because the interface names are p4p1 and p5p1
The interface names are handled by biosdevname/udev.
2) IP aliases and ifconfig are obsolete now. Interfaces can handle multiple IPs easily.
So instead of creating interface aliases, all addresses are added to the same interface.
'ip' command is recommended instead of ifconfig.
$ ip addr
3) not sure what you mean or trying to achieve

TL;DR
What is the actual problem?
Comment 7 Cristian Sava 2013-07-10 15:08:04 EDT
(In reply to Cristian Sava from comment #5)
> On installs where iface reported by "route" command is not the same with
> ifcfg-iface (pxpy instead of enpxsy or ethx) fail2ban will not start.
> Does not matter if biosdevname=0 or net.ifnames=0 on the kernel line.
> Tested this on real hardware and on VirualBox too.
> From /var/log/messages:
> fail2ban-client[2804]: ERROR  Directory /var/run/fail2ban exists but not
> accessible for writing
> Fail2ban is ok on any other install.

Announced as fixed in selinux (selinux was not complaining with AVC and I thought there was a networking problem).
Comment 8 Cristian Sava 2013-07-10 15:44:25 EDT
(In reply to Jirka Klimes from comment #6)
> (In reply to Cristian Sava from comment #0)
> > With F19 install (no updates) it is the same with NM or with network service.
> > 
> > 1) Why "route" shows iface=p4p1, p5p1 instead enp4s0, enp5s0 ?
> > 2) Why "ifconfig" does show only the IPADDR0 without aliases?
> > 3) All is working as expected when 192.168.1.73 is on-line. If ...73 not
> > on-line, the address 193.x.y.162 is assigned to the the server, it responds
> > to "ping 193.x.y.162" but it should be unreachable (or something equivalent)
> > because 192.168.1.73 is off.
> > Similar for 193.x.y.163 .
> > 
> 1) because the interface names are p4p1 and p5p1
> The interface names are handled by biosdevname/udev.
> 2) IP aliases and ifconfig are obsolete now. Interfaces can handle multiple
> IPs easily.
> So instead of creating interface aliases, all addresses are added to the
> same interface.
> 'ip' command is recommended instead of ifconfig.
> $ ip addr
> 3) not sure what you mean or trying to achieve
> 
> TL;DR
> What is the actual problem?
1) Iface name reported by "route" is different from ifcfg-Iface (p5p1 vs. ifcfg-enp5s0) on some installs. All is correct on others (iface=enp5s0 and we have ifcfg-enp5s0).
2) OK, you're right
3) See my iptables. If an addres is used to DNAT:
-A PREROUTING --dst 193.x.y.162 -p tcp -j DNAT --to 192.168.1.73
-A OUTPUT --dst 193.x.y.162 -p tcp -j DNAT --to 192.168.1.73
I think it's logical that if pinging 193.x.y.162 from outside when 192.168.1.73 is off to receive something like "unreachable" or similar (I know that the ip is the kernel's property) but I receive an answer from 193.x.y.162 (it forgot that is set DNAT). Maybe that is only my wish.

The main point is 1) because it is potential source of trouble (e.g. using iptables "-o p5p1" is not "-o enp5s0" if debugging with biosdevname=0, etc.)
I saw that on real hardware and in VirtualBox too.
Comment 9 Fedora End Of Life 2015-01-09 13:38:03 EST
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 10 Fedora End Of Life 2015-02-17 10:48:44 EST
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

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