Network Configuration Issue With Second Public Ip On CentOS 6
Hi folks,
I have a server at Soyoustart.com (which is a brand of OVH). I run CentOS 6.7 and have problems with network configuration.
I want to add a second public ip (failover ip) to the server and did follow the instructions in the CentOS-section of http://hilfe.ovh.de/AdministrationIpAliasHinzufuegen
After executing the required steps I’m not able to reach the host via the second ip from an external host. I tried it with ping and with SSH
commands.
Here the content of the config files (I anonymized the server ip with xx.xx.xx.xx and the failover ip with yy.yy.yy.yy):
$ cat /etc/sysconfig/network NETWORKING=yes HOSTNAME=
NOZEROCONF=true GATEWAY=xx.xx.xx.254
$ cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=static IPADDR=xx.xx.xx.xx NETMASK%5.255.255.0
ONBOOT=yes GATEWAY=xx.xx.xx.254
$ cat /etc/sysconfig/network-scripts/ifcfg-eth0:0
DEVICE=eth0:0
BOOTPROTO=static IPADDR=yy.yy.yy.yy NETMASK%5.255.255.255
ONBOOT=yes
When I restart the network I get a message (two times) saying “RTNETLINK
answers: Operation not supported”.
$ service network restart Schnittstelle eth0 beenden: [ OK ]
Loopback-Schnittstelle beenden: [ OK ]
Loopback-Schnittstelle hochfahren: [ OK ]
Schnittstelle eth0 hochfahren: Determining if ip address xx.xx.xx.xx is already in use for device eth0… RTNETLINK answers: Operation not supported RTNETLINK answers: Operation not supported
[ OK ]
I can see two interfaces eth0 and eth0:0
$ LANG=”” ifconfig eth0 Link encap:Ethernet HWaddr ..:..:..:..:..:..
inet addr:xx.xx.xx.xx Bcast:xx.xx.xx.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:11122 errors:0 dropped:0 overruns:0 frame:0
TX packets:14371 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1362900 (1.2 MiB) TX bytes:3462327 (3.3 MiB)
Interrupt:20 Memory:fe500000-fe520000
eth0:0 Link encap:Ethernet HWaddr ..:..:..:..:..:..
inet addr:yy.yy.yy.yy Bcast:yy.yy.yy.yy Mask:255.255.255.255
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:20 Memory:fe500000-fe520000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:3096 errors:0 dropped:0 overruns:0 frame:0
TX packets:3096 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:274948 (268.5 KiB) TX bytes:274948 (268.5 KiB)
I’m able to reach the host from another host (outside OVH network) via xx.xx.xx.xx (I use ping and ssh), but not via yy.yy.yy.yy.
Just to be sure that there isn’t an issue with the firewall I did
“service iptables stop” and ran the “ping” and “ssh” commands again with the same result. For ip xx.xx.xx.xx it works, but not for yy.yy.yy.yy.
Not sure if this is important, just in case it matters, some additional information:
IPv6 is disabled by kernel parameter “ipv6.disable=1” in /etc/grub.conf
The two mac addresses I see for eth0 and eth0:0 with the “ifconfig”
command are the same. In the OVH/Soyoustart.com GUI I created a virtual mac for the failover ip, I’m not sure if that virtual mac should come into play somewhere?
$ uname -a Linux
21:19:08 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
$ LANG=”” route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface xx.xx.xx.0 * 255.255.255.0 U 0 0 0 eth0
default vss-gw-6k.fr.eu 0.0.0.0 UG 0 0 0 eth0
Why is yy.yy.yy.yy not reachable from outside? What am I doing wrong or what can I do to narrow down the problem?
Regards,
Meikel
7 thoughts on - Network Configuration Issue With Second Public Ip On CentOS 6
this looks weak. Try to use the same netmask as you use for eth0.
best regards Ulf
If I understand IP networking correctly, you only can have “aliases” of the interface appear on the _same_ network segment (I’m tempted to say same class C network) as the main IP of interface, say you have:
DEVICE=eth0
IPADDR=x.y.z.w NETMASK%5.255.255.0
GATEWAY=x.y.z.254
Then with the restriction I mentioned you can have alias:
DEVICE=eth0:0
IPADDR=x.y.z.a NETMASK%5.255.255.255
Note that “x.y.z.” part is the same in both IPs.
Somebody may correct me if I’m wrong.
Valeri
++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++
I have used an 10. Alias on a 192. Interface so it is possible Patrick
I believe you are right. A netmask of 255.255.255.255 however seems wrong. With that netmask a broadcast for address resolution will not work…
well, whats the subnet mask the /rest/ of the 10.x hosts on that physical LAN segment are using ? the alias has to match the network.
NETMASK=255.255.255.255 for alias interface serves very simple purpose. It allows to avoid processing of all broadcasts on particular segment of the network through alias interface as well. As main interface already does it, you don’t want duplication of the same through alias interface. In general, if you make NETMASK=255.255.255.0 for alias, all should work (on Linux I’m sure it will, on FreeBSD you will get an error), but with this setting you do bizarre thing I described above. All these packets are sent to kernel, and the difference is in kernel network stack of Linux and FreeBSD, I figure.
Valeri
++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++
What you’re attempting to do is called “multi-homed routing” and isn’t covered very well by that document. Try this one, or use Google to find another guide:
https://blogs.oracle.com/networking/entry/advance_routing_for_multi_homed
I expect that your host is receiving the ICMP request packets and responding. The problem is the response. The reply packet has the correct source and destination addresses, and the kernel must consult its routing table to determine how and where to send it. There is only one route back to the destination address (the address from which you pinged the system), and that is the default route. Your system sends the packet out that link, where it is probably dropped by an upstream router since it came from an address that they don’t handle.
Your system needs both an additional default route, and rules to determine which route to use for which packets. The above link will help you set up both.
Don’t set GATEWAY here.
As discussed, that’s not a usable NETMASK. You should ignore pretty much everything in the document you linked to.
I’m pretty sure that those are the result of the bad NETMASK.
I would discourage everyone from doing that.
I don’t think there’s any reason to have a virtual MAC.