Networking on RHEL 7 Installations

Latest response

I'd like to break out some threads from the Share your feedback on the RHEL 7 Beta!.

So, please bring your networking topics to this thread and we will look into what you find.

Responses

One issue of interest to us came from a contributor in the main discussion thread: anaconda not picking up networking

In this scenario, the config files had to be edited manually to make the network accessible. I'm looking in to this one right now, has anyone else seen anything similar with networking during the install?

Mark

Given the Fedora Document on Consistent Network Device Naming states that:

Linux guests running under virtualization platforms such as KVM, Xen, VMware Workstation or ESX, or Microsoft Hyper-V will not have their devices renamed.

I was surprised to find my VM's interface is ens192. I added another interface and it was ens224, the next one was ens256. I added a different type of interface and it was ens33, adding another of those is ens34.

How is this in any way consistent? Is there anyway to disable this at install?

We too are seeing complaints about these names.

Hi Benjamin,

Are the interface names consistent with the PCI device numbers? The ensXXX names should be referencing those according to upstream.

I'll add this to my test list, thank you. In the meantime, if the names are too obtrusive, you should be able to add net.ifnames=0 to the kernel command line to revert to old behaviour.

Many thanks,
Mark

They are virtual machines (I have no idea how it determines the device numbers). The physical hosts have 16 NICs.

Adding net.ifnames=0 did work.

Hey,

This worked for me with RHEL7 in VMware:

  1. Edit /etc/default/grub to add the lines:
    net.ifnames=0 biosdevname=0
    to the kernel paramaters
  2. grub2-mkconfig -o /boot/grub2/grub.cfg
  3. Rename /etc/sysconfig/network-scripts/ifcfg-en* to ifcfg-eth*
  4. Set Name=eth* and Device=eth* in /etc/sysconfig/network-scripts/ifcfg-eth*
  5. reboot

This will be a nice switch (not having devices rename). I have this happen a lot. Nearly thought of scripting a mitigation in Perl...

I'm noticing that NetworkManager isn't bringing DHCP interfaces up on-boot. I have to dhclient from a minimal install as well.

Hi Kodiak,

I have found that during the install, to get the interface on first-boot, I have to edit the network configuration and set the interface to be "Always Available", which is the option above, "Allow Users to Control".

Mark

Thanks Mark. I'll have to fiddle with it some more. It seems like a problem that it doesn't come up on it's own during first-boot, especially with a simple single-interface workstation using DHCP.

Even when enabling this thickbox. The network keeps down after a reboot! This is because the network service is not started. service network start did bring up my network.

On the server instances, I omit the package NetworkManager.

That F19 consistent naming scheme is a mess. Bugzilla number 965718 has a bunch of comments. Also see:

http://www.forums.fedoraforum.org/showthread.php?p=1658897#post1658897

Hopefully RHEL 7 addresses these issues better.

  • Greg Scott

What you see wrt device naming in Fedora 19 is what we've seen so far in RHEL 7. I have two very senior admins at my facility who don't agree if this is a great thing or a terrible thing. I lean toward terrible myself.

I'm running VirtualBox 4.3.4 on Windows 8. I have no trouble installing RHEL6.5 as a guest but when I try to install RHEL 7b it will not detect the network adapter. I've tried using different VBox adapter types. Apart from that the installation goes pretty smoothly. Any help is appreciated.

RHEL 7beta won't detect my VIA Rhine ethernet

[root@rhel7beta ~]# dmesg |grep -i eth
[    9.086832] e1000e 0000:00:19.0 eth0: (PCI Express:2.5GT/s:Width x1) e0:69:95:13:5a:5c
[    9.086835] e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network Connection
[    9.086886] e1000e 0000:00:19.0 eth0: MAC: 9, PHY: 9, PBA No: FFFFFF-0FF
[    9.877669] systemd-udevd[550]: renamed network interface eth0 to em1

[root@rhel7beta ~]# lspci -nn|grep -i eth
00:19.0 Ethernet controller [0200]: Intel Corporation 82578DC Gigabit Network Connection [8086:10f0] (rev 06)
01:00.0 Ethernet controller [0200]: VIA Technologies, Inc. VT6105/VT6106S [Rhine-III] [1106:3106] (rev 8b)

[root@rhel7beta ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether e0:69:95:13:5a:5c brd ff:ff:ff:ff:ff:ff
    inet 172.16.2.123/24 scope global dynamic em1
       valid_lft 14050sec preferred_lft 14050sec
    inet6 fe80::e269:95ff:fe13:5a5c/64 scope link
       valid_lft forever preferred_lft forever

Thanks in advance,
Paul

You can find a list of removed (and added) network drivers in EL7 here:

https://access.redhat.com/site/solutions/527083

According to your device ID pairing [1106:3106], it uses via-rhine.ko which is listed under the 'removed' drivers.

Hi Akemi,

Thanks for the info.

Regards,
Paul

on RHEL 7 SNAPSHOT 1 When I am in anaconda and click on configure network it crashes everytime. System is detecting network as p2p instead of wired ethernet

are we expected to follow Fedora guidelines on disabling network manager and firewalld?


systemctl stop NetworkManager.service
systemctl disable NetworkManager.service
systemctl enable network.service
systemctl start network.service

yum install iptables-services
systemctl mask firewalld.service
systemctl enable iptables.service
systemctl enable ip6tables.service
systemctl stop firewalld.service
systemctl start iptables.service
systemctl start ip6tables.service


Is it safe to remove firewalld from the KickStart scripts? How safe is it to remove NetworkManager as well (we have no use for it in our setup)?

My network adapter is not recognized by RHEL 7 beta installed on VMware.
the output of `lspci -nn |grep -i eth' shows:

02:01.0 Ethernet controller [0200]: Advanced Micro Devices, Inc. [AMD] 79c970 [PCnet32 LANCE] [1022:2000] (rev 10)

dmesg |grep -i eth shows some un-related result as the following:

[ 257.265487] Bluetooth: BNEP (Ethernet Emulation) ver 1.3

Is this because the driver was removed in RHEL 7 beta? and how to resolve it?
Thanks.

Yes, the pcnet32 driver has been removed. Use the emulated Intel e1000 device, or preferably the paravirtualized VMWare vmxnet3 device.

hey i am facing the same problem can u please help me out

I have been having an interesting time with nmcli in RHEL7. I must admit, I completely avoid Fedora so I am likely behind the class with RHEL7 changes. I have been following the documentation here:
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/7-Beta/pdf/Networking_Guide/Red_Hat_Enterprise_Linux-7-Beta-Networking_Guide-en-US.pdf

I appreciate that it is in draft, but it needs some work to correct unnecessary ambiguity in instructions.

Example from page 49:
"To add an Ethernet connection with manual IP configuration, issue a command as follows:"

 nmcli con add con-name my-eth1 ifname eth1 type ethernet ip4 192.168.100.100/24 gw4 192.168.100.1 ip4 1.2.3.4 ip6 abbe::cafe

This command unnecessarily confuses the situation by introducing more than necessary. As far as I can tell, this isn't adding a single static IP, it is adding 3 IP's (two IP4 the other IP6) and one IP4 address specifies a gateway the others don't. It also uses the 'old' style device naming convention of 'eth0'.

All that is required in this example is something along the lines of:

nmcli con add con-name production-lan ifname eno16777736 type ethernet ip4 192.168.100.100/24 gw4 192.168.100.1

Also wondering if this section is still required (also page 49):
"To lock this connection to a specific MAC address, issue a command as follows:"

nmcli connection edit type ethernet con-name "my-eth1" mac 00-00-5E-00-53-00

With persistent device naming, shouldn't referencing the en* device name in the connection profile be enough to ensure that it doesn't move to another NIC?

Note: eno16777736 is the real name given to my eth device under VMWare fusion... soon I will start referring to it by MAC address to save on typing!

Interested to see some suggestions about the minimum number of commands to get networking up with gateway/DNS (using nmcli) to see if I am missing anything, is everyone else using nmcli to configure their nics in RHEL7? or resorting to editing files or using the GUI?

Also interested to know if there is a way to list connection profiles and the physical device they are associated with (without bash tomfoolery).

ie. the following command that also lists associated 'en' devices.

nmcli con show

Lastly, is it safe to assume that RHEL 7 final will be using iptables not NFTables?

-edit-

Should add that I don't mind the nmcli interactive configuration mode.. some of the key bindings are a bit interesting.. but it is a refreshing approach to Linux config.

PixelDrift--

I agree that the example on p. 49 is bad, but I only see 2 IP addresses being assigned (one v4, one v6). I think either you or I may be getting confused by the presence of both a static IPv4 address (1.2.3.4) and an IPv4 subnet/mask given in CIDR form (192.168.100.100/24) - but that is an invalid CIDR subnet! (a /24 cannot have anything other than 0 in the 4th octet). Giving a static IP that is not on the same subnet is bogus, too (theoretically possible depending on the router configuration, but absolutely NOT normal, and should not be used in an "example" unless the doc very clearly mentions that this is a non-standard (but legal) configuration.

Examples given should always be as close as possible to correct and valid--so if an example uses a subnet in RFC 1918 space, the static IP assigned should be on that subnet, not "1.2.3.4".

James,

Not getting confused at all, that line represents 3 addresses. I followed the command and validated the output in nmcli.

The reason that isn't a valid CIDR subnet is because it is specifying an IP4 address and subnet mask in one

192.168.100.100/24

is essentially shorthand for 192.168.100.100 / 255.255.255.0.

This also isn't explained in the documentation, but as you will see from my suggested command to add a single IP (from the post you commented on)

nmcli con add con-name production-lan ifname eno16777736 type ethernet ip4 192.168.100.100/24 gw4 192.168.100.1

It is perfectly valid and the suggested method for supplying an address when using nmcli.

The 3 addresses are specified in the command immediately after 'ip4' (twice) and 'ip6'

Hello

I will try to improve those examples.

Thank you for the feedback.

What is the preferred method for changing an interface's setttings? Previously, editing /etc/sysconfig/network-scripts/ifcfg-xxx then "service network restart" did the trick.

On RHEL 7, after editing the ifcfg file, nothing short of a reboot seems to get it to use that config. I've tried "service network restart" I've tried "systemctl restart network.service" as well as "systemctl stop network.service" followed by "systemctl start network.service" Those don't seem to actually do anything. I need to reboot to get the new config to work.

Michael, did you check out the RHEL 7 Networking Guide?

Maybe I just glossed over it (read too quickly), but I don't see it mention a command to reload a new config in the ifcfg files. It just says that those files are used at boot. So there is no longer a way to do this without rebooting? I don't even want NetworkManager installed.

A little late, but the command you're missing (if you're using NM) is:

  • nmcli connection reload

Which can be shortened to:

  • nmcli c r

That will reload the ifcfg files after manual edits. From there if you want to re-up a connection whose file you changed, you need to manually do so with another nmcli connection command, e.g.:

  • nmcli c up "System eno1"

Note that you don't actually need to take an interface down first, like in the old days (e.g., with ifdown eth0 followed by ifup eth0).

I also understand your desire to avoid NetworkManager altogether Michael. There are PLENTY of people here at Red Hat that feel the same way; however, as someone who teaches RHEL to internal employees (and used to teach to paying customers), I would just like to offer that I have yet to meet someone who is still dismissive of RHEL7 NetworkManager after learning how it works -- the common thread amongst all the folks I've met that are annoyed with it ... well, simply boils down to them not wanting to learn why NM is there or what it can offer.

One last data point: I've been using RHEL for years, teaching RHEL for years, and worked in Red Hat's support department for 2 years ... and I can say that I have never recommended NM for servers in RHEL 6 and below, ever. That said, RHEL 7's NetworkManager is a whole 'nother ballgame. I've been sold on it. I would suggest that if you learn a bit about it too, e.g., how it integrates with systemd vs the old-school way the network service script operates -- I think you'll agree: it's the future.

For anyone who simply doesn't want to learn, well, that's okay too. Thankfully you don't have to use it if you don't want to. I'd recommend reading this section in the RHEL 7 Networking Guide for more on that.

My opinion is the same. NM in EL6 is not feature-complete, I always disable it. However, NM in EL7 is fantastic. I now prefer using it over the old initscripts.

At least with the latest versions of Fedora, where RHEL comes from, you can do:

systemctl stop NetworkManager.service
systemctl disable NetworkManager.service
chkconfig --level 345 network on
service network start

And then it goes back to the old way of doing things, except the device names are different. Notice the big N and M in NetworkManager. And network, at least as of Fedora 20, still does its startup/shutdown the old way.

And then for changing the ifcfg-nnn files, you can do ifdown {nnn} and ifup {nnn} just like before as long as NetworkManager isn't running.

  • Greg

Thanks! Looks like if NM is running, it completely ignores the ifcfg files and just does whatever it feels like. I really wish NetworkManager was not on by default.

I will try and replicate your issue as I generated my ifcfg files using nmcli (Network Manager) and restarted networking and don't recall having any issues.

Unfortunately, NetworkManager (along with authconfig) seems to be something that Red Hat just aren't going to give up on.

At this point in time I am still trying to convince myself that they have done enough work on NM for RHEL7 that I should give it a chance..

What was happening for me was that it was forcing my interface to get an address from dhcp even though I had it configured for a static address in the ifcfg file. I had to stop NetworkManager in order for it to work properly.

I guess I just don't understand the point of NetworkManager. Configuring interfaces via the ifcfg files is so simple and straight forward. Why complicate it?

I agree in regards to NM, and have turned it off in all RHEL 6 builds I manage.

I believe what they are attempting to achieve is a 'simpler' process for non technical people who are intimidated by editing configuration files (not suggesting I agree with the approach).

Like 'authconfig', NetworkManager is looking after multiple files in a single go (/etc/hosts, /etc/resolv.conf, /etc/sysconfig/network, /etc/sysconfig/network-scripts/ifcfg-*). The problem with both NM and authconfig I have found, is that for existing/experienced users it tells you very little about what is going on and what it's doing to the files, which is what causes a lot of the frustration.

I believe the push for NetworkManager in RHEL 7 (may be completely wrong) revolves around the ability to make interface 'profiles' easier for desktop/laptop users, eg. you go to the office the NIC uses configuration 'A', when you're at home it switches to configuration 'B', something that editing ifcfg files doesn't really accommodate.

The same argument about being able to edit configuration files / simplicity of editing files directly has been raised about systemd in many of the discussions revolving around the replacement of the init system.

Very salient points.

We do not use NetworkManager in our environment but configure using the ifcfg files as well. We even omit NetworkManager in all our kickstarts.

In response to PixelDrift.NET Support:

Hey there. As you do your research and form your opinions about NM, you might be interested in reading what I responded to Michael in a separate section of this thread.

I would also just like to say that from what I've seen, this "push" to use NetworkManager has virtually nothing to do with making networking "profiles" easier to manage for laptop & desktop users. NetworkManager provides so much more than that.

Thanks for the write up Ryan,

My belief on the 'push' was based on what I had been exposed to from Red Hat at the time of posting, the choice in direction that Red Hat takes is often left to best guess to end users because the reasons as to 'why' seem to be rarely expressed.

I appreciate your additional information, and think everyone would benefit from further discussion in regards to your point "NetworkManager provides so much more than that".

I had provided a decent amount of feedback regarding the RHEL7 Networking documentation above in the hope that it would be rectified to be clearer to RHEL7/NetworkManager converts (me included).

I personally will be using NetworkManager in RHEL 7 (after spending more time with it) but my thoughts on its implementation on RHEL 6 remain unchanged and I think the NM in RHEL6 legacy is half the battle when pushing adoption in RHEL 7.

I could become a NM fan. Quick story - I have a Fedora 20 firewall around 600 miles away at a remote branch site with unreliable Internet service. It connects to the main office using an OpenVPN tunnel. We back up the DSL feeding the site with a cell phone data plan. The hardware has a WiLAN card inside and the cell carrier feeds a MiFi device. So the firewall connects to the DSL modem over a wire and the MiFi over WiFi. There's an nmcli command to connect to the wireless SSID and NM senses when the wired connection is up. When the wired connection is up, NM sets the default GW that way and the tunnel goes out the wire. When the wired connection is down, NM sets everything up over WiFi. It's a thing of beauty. It's not perfect failover because it doesn't measure the next-hop outside the default gateway, but I like the way it quickly brings up wired or wireless and prioritizes the right way.

That's what I like. What I don't like is, I lose control with NM and it doesn't make sense in most routing scenarios. My small remote site is a special case.

But in cases where Linux is a DHCP client and has a choice of wired and wireless connections, the latest and greatest NM looks nice.

  • Greg

vi /etc/sysconfig/network
NETWORKING=yes
HOSTNAME=vm16
GATEWAY=192.168.1.1

systemctl stop NetworkManager.service
systemctl disable NetworkManager.service
systemctl enable network.service
systemctl start network.service

yum install iptables-services
systemctl mask firewalld.service
systemctl enable iptables.service
systemctl enable ip6tables.service
systemctl stop firewalld.service
systemctl start iptables.service
systemctl start ip6tables.service

Can someone give a better / more succinct explanation as to why /etc/resolv.conf perms changed?

There is an 'answer' here
https://access.redhat.com/site/solutions/196443

The file has changed from 0644 to 0444, and the above link suggests it's because 'dnssec-trigger' manages it and wants to avoid external modification, but when is dnssec-trigger called?
Will it be updated by NM?
Will it be updated by modifying the ifcfg files directly?

Is this a move in the general direction of stopping administrators modifying cfg files in preference of using tools like NM?

If you modify dnssec-trigger.conf and start the dnssec-triggerd.service, then /etc/resolve.conf will change to 0444.

/etc/dnssec-trigger/dnssec-trigger.conf
# where is resolv.conf to edit.
resolvconf: "/etc/resolv.conf"

 ~]# systemctl start dnssec-triggerd.service      
 ~]# cat /etc/resolv.conf 
# Generated by dnssec-trigger 0.11
nameserver 127.0.0.1

 ~]# ll /etc/resolv.conf 
-r--r--r--. 1 root root 56 Jun 12 18:01 /etc/resolv.conf

 ~]# systemctl stop dnssec-triggerd.service

 ~]# cat /etc/resolv.conf 
# Generated by NetworkManager
domain example.com
search example.com
nameserver 192.168.122.10

 ~]# ll /etc/resolv.conf 
-rw-r--r--. 1 root root 112 Jun 12 18:05 /etc/resolv.conf

I'm not sure if my comment is sufficient to you. Sorry.

Thanks Yoko,

My question really was, what is the point of dnssec-trigger, what existing function does it replace or remove that means it takes control of /etc/resolv.conf?

Now having time to read up on it, dnssec-triggerd essentially intercepts DNS queries and forwards them to a local DNS server instance listening on 127.0.0.1 (unbound DNS service) if the selected resolvers don't support DNSSEC.

So I guess my question now is, is NetworkManager dnssec-trigger aware? because it also likes to manage /etc/resolv.conf.. or are the 0444 perms used to stop NetworkManager updating it?

Try setting PEERDNS=no in the ifcfg file.

Hi Tim, cheers for the response.
I understand updating PEERDNS will stop NetworkManager from modifying resolv.conf but my question revolves around how NetworkManager deals with dnssec-trigger essentially 'taking control' of a file NetworkManager expects to be able to read/write (if required).

You end up in a situation where there are essentially two packages that think they 'manage' /etc/resolv.conf.

Pages