Networking on RHEL 7 Installations
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
Red Hat
Guru
1638 points
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
Community Member
68 points
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?
Red Hat
Guru
1638 points
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
Community Member
68 points
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:
- Edit /etc/default/grub to add the lines:
net.ifnames=0 biosdevname=0
to the kernel paramaters - grub2-mkconfig -o /boot/grub2/grub.cfg
- Rename /etc/sysconfig/network-scripts/ifcfg-en* to ifcfg-eth*
- Set Name=eth* and Device=eth* in /etc/sysconfig/network-scripts/ifcfg-eth*
- reboot
Expert
1004 points
I'm noticing that NetworkManager isn't bringing DHCP interfaces up on-boot. I have to dhclient from a minimal install as well.
Red Hat
Guru
1638 points
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
Expert
1004 points
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.
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
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
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.
Red Hat
Guru
11464 points
Yes, the pcnet32 driver has been removed. Use the emulated Intel e1000 device, or preferably the paravirtualized VMWare vmxnet3 device.
Guru
6683 points
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.
Guru
1900 points
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".
Guru
6683 points
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'
Guru
6827 points
Pixel,
they moved the network guide here https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/index.html
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.
Red Hat
Guru
3695 points
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.
Red Hat
Guru
3868 points
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.
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.
Guru
6683 points
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?
Guru
6683 points
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.
Red Hat
Guru
3868 points
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.
Guru
6683 points
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
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
Guru
6683 points
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.
Guru
6683 points
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.
Guru
6683 points
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.