Hello,
I'm trying to set up IP aliases within a QEMU/KVM guest on CentOS 5.5 x86_64, going through a bridged virtualized interface.
The virtualized interface in the guest is configured as follow:
# ifcfg-eth1
DEVICE=eth1 BOOTPROTO=none PEERDNS=yes GATEWAY=IP.OF.HOST.GATEWAY HWADDR=11:11:11:11:11:11 IPADDR=IP.OF.GUEST.ETH1 NETMASK=255.255.255.255 ONBOOT=yes ARP=yes USERCTL=no IPV6INIT=no
# route-eth1
IP.OF.HOST.GATEWAY dev eth1 default via IP.OF.HOST.GATEWAY dev eth1
This is the configuration recommended by the provider (OVH) after a virtual MAC address has been allocated for IP.OF.GUEST.ETH1: http://help.ovh.com/BridgeClient
It works fine for virtual interfaces added via libvirt/QEMU.
But when I try to configure an IP alias on another IP address aliasing a virtualized interface, as per the instructions from http://help.ovh.co.uk/IpAlias (and after assigning it a virtual mac just like for eth1) :
# ifcfg-eth1:1
DEVICE=eth1:1 BOOTPROTO=none PEERDNS=yes GATEWAY=IP.OF.HOST.GATEWAY HWADDR=22:22:22:22:22:22 IPADDR=IP.OF.GUEST.ETH1:1 NETMASK=255.255.255.255 ONBOOT=yes ARP=yes USERCTL=no IPV6INIT=no
I get the following error when restarting the network:
SIOCADDRT: Network is unreachable
and IP.OF.GUEST.ETH1:1 is: - pingable from the same guest - not pingable from other guests by the same provider - not pingable from outside
Setting BOOTPROTO=static or commenting out #GATEWAY=IP.OF.HOST.GATEWAY or setting: NETMASK=255.255.255.252 (the IP block was a /30, but I don't think that has something to do here)
did not change the behavior.
I'll be interested to hear from experiences with setting IP alias from within a guest. Maybe my problem is due to the configuration of the provider network and it is actually impossible to use IP aliases on virtualized interfaces. Any opinion/idea welcome!
Mathieu
Hello,
I'm trying to set up IP aliases within a QEMU/KVM guest on CentOS 5.5 x86_64, going through a bridged virtualized interface.
The virtualized interface in the guest is configured as follow:
# ifcfg-eth1
DEVICE=eth1 BOOTPROTO=none PEERDNS=yes GATEWAY=IP.OF.HOST.GATEWAY HWADDR=11:11:11:11:11:11 IPADDR=IP.OF.GUEST.ETH1 NETMASK=255.255.255.255 ONBOOT=yes ARP=yes USERCTL=no IPV6INIT=no
# route-eth1
IP.OF.HOST.GATEWAY dev eth1 default via IP.OF.HOST.GATEWAY dev eth1
This is the configuration recommended by the provider (OVH) after a virtual MAC address has been allocated for IP.OF.GUEST.ETH1: http://help.ovh.com/BridgeClient
It works fine for virtual interfaces added via libvirt/QEMU.
On first reading I thought eth1 would have been your second interface within the guest, besides eth0. Meanwhile I think you just skipped eth0.
That is because you can have just 1 default route. The OVH document does not describe a setup for a 2nd interface.
Well, even for the 1st interface some settings are strange / unnecessary.
Especially when dealing with more than 1 interface, do NOT set the GATEWAY in ifcfg-ethX. By principle always set GATEWAY (in your case GATEWAY=x.y.z.254) in /etc/sysconfig/network. Thus you do not need the route-ethX configuration file, defining a network and a default route. All that is done automatically.
If you would have more than 1 interface (the OVH doc does not indicate to be written for such a case, neither notes explicitly to give problems in that case), then following the OVH doc gives you trouble.
But when I try to configure an IP alias on another IP address aliasing a virtualized interface, as per the instructions from http://help.ovh.co.uk/IpAlias (and after assigning it a virtual mac just like for eth1) :
# ifcfg-eth1:1
DEVICE=eth1:1 BOOTPROTO=none PEERDNS=yes GATEWAY=IP.OF.HOST.GATEWAY HWADDR=22:22:22:22:22:22
An aliases interface does not have an own MAC, it is physically the same MAC as the primary interface.
IPADDR=IP.OF.GUEST.ETH1:1 NETMASK=255.255.255.255 ONBOOT=yes ARP=yes USERCTL=no IPV6INIT=no
I get the following error when restarting the network:
SIOCADDRT: Network is unreachable
You created a route-eth1:1 file?
and IP.OF.GUEST.ETH1:1 is:
- pingable from the same guest
- not pingable from other guests by the same provider
- not pingable from outside
The network infrastructure of the hoster must permit the IP address used to come from MAC of your system.
Setting BOOTPROTO=static or commenting out #GATEWAY=IP.OF.HOST.GATEWAY or setting: NETMASK=255.255.255.252 (the IP block was a /30, but I don't think that has something to do here)
did not change the behavior.
The netmask of 255.255.255.255 is given by intention because of the network layout of your hoster.
I'll be interested to hear from experiences with setting IP alias from within a guest. Maybe my problem is due to the configuration of the provider network and it is actually impossible to use IP aliases on virtualized interfaces.
Yes, as said, the security design of the hoster must permit the use of defined IPs bound with a dedicated MAC. Ask you hoster.
You can add additional IPs to virtualized interfaces - either by definining aliased devices or by adding IPs with the help of "ip addr add" - but that does not mean they are usable automatically. It is a matter of security in a hosting / virtualized hosting environment.
Any opinion/idea welcome!
Mathieu
Alexander
On first reading I thought eth1 would have been your second interface within the guest, besides eth0. Meanwhile I think you just skipped eth0.
There is a eth0 interface, but it is connected to the internal NAT network of libvirt. That way I have a LAN between my guests and eth1 is used for external access.
That is because you can have just 1 default route. The OVH document does not describe a setup for a 2nd interface.
Yes I did have issue with that because the DHCP on eth0 was setting a gateway. I solved it by forcing:
GATEWAY=IP.OF.HOST.GATEWAY (=x.y.z.254)
in eth0 as well.
Here is the ifcfg-eth0:
# Virtio Network Device DEVICE=eth0 BOOTPROTO=dhcp HWADDR=33:33:33:33:33:33 ONBOOT=yes GATEWAY=IP.OF.HOST.GATEWAY
Especially when dealing with more than 1 interface, do NOT set the GATEWAY in ifcfg-ethX. By principle always set GATEWAY (in your case GATEWAY=x.y.z.254) in /etc/sysconfig/network. Thus you do not need the
ok, good to know, I will fiddle with that.
If you would have more than 1 interface (the OVH doc does not indicate to be written for such a case, neither notes explicitly to give problems in that case), then following the OVH doc gives you trouble.
It actually works fine when I had many virtualized interfaces (eth2, eth3, etc.). And I actually don't need to add other route-eth2, route-eth3, etc. (because route-eth0 set the default gateway, isn't it?)
An aliases interface does not have an own MAC, it is physically the same MAC as the primary interface.
maybe that is were I am doing something wrong, because I configured this virtual MAC within OVH.
You created a route-eth1:1 file?
yes, I tried that but it did not help. and as put above it was not necessary for the other virtual interfaces.
Yes, as said, the security design of the hoster must permit the use of defined IPs bound with a dedicated MAC. Ask you hoster.
I will ask them, they are pretty helpful in general.
You can add additional IPs to virtualized interfaces - either by
good to know that is feasible
Thanks for your help!
On 08/13/2010 04:48 PM, Mathieu Baudier wrote:
NETMASK=255.255.255.255?
it surprised me as well first, but that is what OVH recommends and it works fine with virtual interfaces
That just means that the connected "network" contains only one machine. Depending on the actual topology this might be a bit inefficient but probably not in a serious way.
Sending traffic from 192.168.0.10 to 192.168.0.11 with a netmask of 255.255.255.0 will result in the traffic flowing directly between the machines because the system knows the target is part of the same subnet.
Using 255.255.255.255 as netmask means the system will no longer see the target as part of the same subnet and as a result will send the traffic to the default gateway instead which will then forward it to the target.
Regards, Dennis
-
Alexander Dalloz -
compdoc -
Dennis J. -
Mathieu Baudier