I followed the instructions at this link:

http://www.tecmint.com/create-multip...ork-interface/

attempting to attach a second ip address ("IP alias") to the eth0
NIC port.

When I ran 'service network restart' it hung, and after that I was not able to login nor ping the server at either its eth0 or eth1 address. I had to reboot the system via a DRAC (Dell Remote Access Controller).

All I did was create a new file /etc/sysconfig/network-scripts/ifcft-eth0:0 and modify the DEVICE and IPADDR lines.

Any idea why this would crash? And if this was the wrong way to go about this, what is the right way?

My OS is RHEL 5.8.

Thanks,
Sanford Stein
CyberTools Inc.

Depends on how hard the crash was and if you had any sort of reporting set up. Look at /var logs maybe to start.

To be exact, you don't know what caused the issue yet. Don't limit your troubleshooting to just nic.


You should also have factory support from Red Hat so consider using their helpdesk or use their web pages. This is a different version but see the correct doc's for the one you have. https://access.redhat.com/site/docum...ces-alias.html

Did it really hang the system? What do the logs say?

I've never seen this truly hang a system before, but anything is possible...it's Linux

Thanks for your prompt responses.

GaWdLy: 'service network restart' hung my session, and I was unable to login again through either of my NIC ports (as if they were not recognizing their IP addresses). The only thing I see in /var/log/messages is: "etc/sysconfig/network-scripts/ifup-eth: Failed to bring up eth0" (repeatedly).

jefro: The Red Hat link you provide describes the method I used, but also has several warnings about it. It points you to documentation on Network Manager, but I do not have a GUI interface and need to know how to do this from the shell. I guess I can submit a ticket.

Sanford, I wouldn't call that a hang, necessarily, but I understand.

Clearly, when it ifup'd, it ran into a configuration issue, and the IFs were unreachable.

Sanford, what is the output of 'service NetworkManager status'? If you are going to manually configure the aliased address, just make sure that the service is off.

GaWdLy: NetworkManager service is stopped. I work remotely, do not have a GUI interface, so I never use it.

I found this: https://access.redhat.com/site/solutions/8672 which recommends an alternate approach. I'll try it on Monday morning.

Thanks for your assistance.

Sanford, the NM doesn't need the UI to run.

I've always had better luck using the IPADDRx and PREFIXx method, as opposed to the ifcfg-ethx:y method.

So I suggest this method:

1 members found this post helpful.

GaWdly: That's exactly what was recommended in the Red Hat doc. Not wanting to be stuck here on the weekend with a crashed system, I plan to try it on Monday morning. Thanks for your confirmation that this is the right way to go.

I think this is the v5 doc. https://access.redhat.com/site/docum...ces-alias.html

GaWsLy and jefro:

I have tried both methods of doing this:
1. Creating /etc/sysconfig/network-scripts/ifcfg-eth0:0
2. Adding IPADDR2 and NETMASK2 to /etc/sysconfig/netword-scripts/ifcfg-eth0

In both cases, trying to restart the network (service network restart for #1 and ifup eth0 for #2) hangs and causes the NIC to lose its IP and requires a reboot using a DRAC. Here is my ifcfg-eth0 file, with the two new lines commented out:

DEVICE=eth0
ONBOOT=yes
IPADDR=66.205.80.68
HWADDR=00:18:8b:45:09:a0
GATEWAY=66.205.80.65
BROADCAST=66.205.80.71
BOOTPROTO=none
NETMASK=255.255.255.248
TYPE=Ethernet
USERCTL=no
IPV6INIT=no
PEERDNS=yes
#IPADDR2=66.205.80.70
#NETMASK2=255.255.255.248

Is my problem that the netmask does not end in '0' like all of Red Hat's examples? Any other thoughts?

Thanks,
SS

SS:

What is the output of '# rpm -q NetworkManager' ? Is it NetworkManager-0.8.1-61.el6.x86_64 or later?

Have you tried this method in https://access.redhat.com/site/solutions/8672 :

~~~
Configuring the old way with Network Manager (0.8.1-61 or newer)
Notes:
- The ONPARENT= option isn't supported by Network Manager currently.
- It isn't possible to configure the additional IP address for the old way using the Network Manager's graphical interface.

This method requires another ifcfg file named as ifcfg-:

See an example below of an alias interface with IP address 172.33.33.1/255.255.255.0

# cat /etc/sysconfig/network-scripts/ifcfg-eth0\:1
DEVICE=eth0:1
ONPARENT=yes
IPADDR=172.33.33.1
NETMASK=255.255.255.0
Then bring up the interface to make the changes effective:

# ifup eth0:1
~~~

Note the bolded section above. You don't need to perform service network restart using this method. Just ifup the 0:1 IF.

I'll download RHEL 5.8 and see if I can reproduce. If so, then I'll need to change the doc to be more clear (either by suggesting a different version of the NM, or by excluding RHEL 5 from the article instead of "All Versions, as the article implies.

1 members found this post helpful.

GaWdLy,

[root@cedar ~]# rpm -q NetworkManager
NetworkManager-0.7.0-13.el5

I followed your instructions and it "worked" in that there now appear to be two IPs associated with 'eth0':

[root@cedar ~]# /sbin/ip address list dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:18:8b:45:09:a0 brd ff:ff:ff:ff:ff:ff
inet 66.205.80.68/29 brd 66.205.80.71 scope global eth0
inet 66.205.80.70/29 brd 66.205.80.71 scope global secondary eth0:1
inet6 fe80::218:8bff:fe45:9a0/64 scope link
valid_lft forever preferred_lft forever

But I cannot ping or ssh the new ip from a remote system, so the current configuration is not really useful.

Thanks for your continued willingness to help here,
SS

SS:

I installed RHEL 5.8. I configured an alias using the ifcfg file method (AKA "the old way"). It works:
~~~
# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 52:54:00:84:d9:04 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.122/24 brd 192.168.122.255 scope global eth0 <-- Primary
inet 192.168.122.132/24 brd 192.168.122.255 scope global secondary eth0:1 <-- Secondary
~~~

I followed your config, above and was also able to set the alias:

~~~
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 52:54:00:84:d9:04 brd ff:ff:ff:ff:ff:ff
inet 66.205.80.65/29 brd 66.205.80.71 scope global eth0
inet 66.205.80.70/29 brd 66.205.80.71 scope global secondary eth0:1
~~~

I do not have any messages in /var/log/messages about having trouble setting the address on eth0. I experimented some, and was still unable to duplicate it. I set BOOTPROTO to 'static' instead of 'none' (AFAIK, 'none' only needs to be used for bonding). That still didn't do the trick.

I'm really weak on my subnets, but I think you may be running into an issue of addressing. I could totally be wrong, since as I said, this is a huge weak spot...

on a .248 /29 network, shouldn't your addresses be from .249-.254, and have a broadcast of .255?

http://www.aelius.com/njh/subnet_sheet.html

1 members found this post helpful.

GaWdLy,

Thank you for running this experiment. I was able to get the NIC to recognize the second IP, but cannot ping or ssh to the new IP so it is not of much use. I am assuming that you WERE able to recognize the seconary IP from an outside server.

Looking at your link, at the "Guide to Subclass C Blocks", I note that one legitimate range for netmask .248/29 is .64 to .71, which is what we use. We lease these IPs from the colocation facility, so my best guess at this point is that there is a problem with their router/switch configuration, or perhaps they need to perform some operation on the router to put this IP into effect. I will pursue that path.

Thanks,
SS

SS:

In my initial experiment (enabling an IP alias on my local network), I was able to set 192.168.122.122 and 192.168.122.132 on the same IF and log in using the .132 IP address.

I didn't duplicate your IP range here, though.

I think you're probably right-they may have one or more pieces of hardware that is misconfigured at this point.