CentOS 7 networking issues
-
and
nmcli device showis different.[root@nginix ~]# nmcli device show GENERAL.DEVICE: eth0 GENERAL.TYPE: ethernet GENERAL.HWADDR: 02:15:5D:01:03:09 GENERAL.MTU: 1500 GENERAL.STATE: 100 (connected) GENERAL.CONNECTION: eth0 GENERAL.CON-PATH: /org/freedesktop/NetworkManager/ActiveConnection/1 WIRED-PROPERTIES.CARRIER: on IP4.ADDRESS[1]: 10.201.1.18/24 IP4.GATEWAY: 10.201.1.1 IP4.DNS[1]: 10.201.1.7 IP4.DOMAIN[1]: domain.local IP6.ADDRESS[1]: fe80::fb6c:e1ec:b116:5220/64 IP6.GATEWAY: GENERAL.DEVICE: lo GENERAL.TYPE: loopback GENERAL.HWADDR: 00:00:00:00:00:00 GENERAL.MTU: 65536 GENERAL.STATE: 10 (unmanaged) GENERAL.CONNECTION: -- GENERAL.CON-PATH: -- IP4.ADDRESS[1]: 127.0.0.1/8 IP4.GATEWAY: IP6.ADDRESS[1]: ::1/128 IP6.GATEWAY: -
First thing I do on CentOS is disable Network Manager. I hate it.
-
@Tim_G said in CentOS 7 networking issues:
First thing I do on CentOS is disable Network Manager. I hate it.
Wrong answer, sorry. Network manager is the new default. You should get used to it and use it appropriately.
-
So I changed it to static like this.
-
Part of my CentOS routine:
-
Change run level: nano /etc/inittab (use id:3:initdefault:)
-
cd /etc/rc.d/rc3.d
-
ls -lh
-
mv S23NetworkManager K23NetworkManager
-
Reboot
-
ls -l /etc/sysconfig/network-scripts (to see what's there)
-
nano /etc/sysconfig/network-scripts/ifcfg-eth0
(if dhcp)
DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=yes
(save it)
ifup eth0
chkconfig network on -
-
Network Manager, still throwing admins for a loop even after all these years
-
NetworkManager still creates the ifcfg files under network-scripts. So those configs will still be there, but should have NM_CONTROLLED=yes
Also, for some reason CentOS ships with both network and NetworkManager on at the same time. So that's most likely why you saw the DHCP for NetworkManager and the static file that you created. I always disable and mask network to keep people from turning it back on when they aren't paying attention.
-
@Tim_G said in CentOS 7 networking issues:
Part of my CentOS routine:
-
Change run level: nano /etc/inittab (use id:3:initdefault:)
-
cd /etc/rc.d/rc3.d
-
ls -lh
-
mv S23NetworkManager K23NetworkManager
-
Reboot
-
ls -l /etc/sysconfig/network-scripts (to see what's there)
-
nano /etc/sysconfig/network-scripts/ifcfg-eth0
(if dhcp)
DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=yes
(save it)
ifup eth0
chkconfig network onTargets (run levels) are handled through systemd now so you should use systemctl set-default multi-user.target.
And as @JaredBusch said, NetworkManager is the new default, and handles things like teaming much better.
-
-
@stacksofplates Didn't realize he was being forced to use defaults. Since that's the case, I guess he has no other option than to use Network Manager?
-
@Tim_G said in CentOS 7 networking issues:
@stacksofplates Didn't realize he was being forced to use defaults. Since that's the case, I guess he has no other option than to use Network Manager?
No one is forcing me to use anything. But use of defaults is a best practice. without a really good reason, you do not stray from them.
-
@JaredBusch said in CentOS 7 networking issues:
@Tim_G said in CentOS 7 networking issues:
@stacksofplates Didn't realize he was being forced to use defaults. Since that's the case, I guess he has no other option than to use Network Manager?
No one is forcing me to use anything. But use of defaults is a best practice. without a really good reason, you do not stray from them.
Losing VM functionality due to time issues because of a default isn't a good enough reason? Isn't it a production VM? Does it being down not lose the company money on top of paying you to mess with it? I'd rather use a non-default that works just as well for a particular function or task, rather than having to waste so much of a clients money to fix something that can arguably be replaced with something else non-default. Maybe Network Manager handles teaming better, but are you using teaming? Are you using teaming at the VM level or at the Hypervisor level? Just do what's best for the client. Don't use a default because it does something better with something you aren't even using. Know what I mean?
Maybe for your case it's worth it to get Network Manager working properly due to other things I don't know about. I'm not giving a blanket statement, just throwing out a point is all.
Sometimes best practice is a square, and what you are dealing with is a circle. It might not fit.
-
@Tim_G said in CentOS 7 networking issues:
Losing VM functionality due to time issues because of a default isn't a good enough reason
That's not the reason. The downtime was due to both services running. I have literally never had a network issue with just NetworkManager running. It also takes about 10 seconds to set up an interface through NetworkManager, it's much simpler.
Also network is being phased out, and not receiving feature updates. So while you can use it currently, it's most likely not going to be there in 8.
And yes, I am using teaming, but on the host.
-
@stacksofplates said in CentOS 7 networking issues:
NetworkManager still creates the ifcfg files under network-scripts. So those configs will still be there, but should have NM_CONTROLLED=yes
Also, for some reason CentOS ships with both network and NetworkManager on at the same time. So that's most likely why you saw the DHCP for NetworkManager and the static file that you created. I always disable and mask network to keep people from turning it back on when they aren't paying attention.
So it looks like they took out the NM_CONTROLLED section. I must have been thinking of RHEL 6. But NM still creates the ifcfg files in the same directory.
