FAQ
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
IPADDR=IP.OF.GUEST.ETH1
NETMASK%5.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
IPADDR=IP.OF.GUEST.ETH1:1
NETMASK%5.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%5.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

Search Discussions

  • Alexander Dalloz at Aug 13, 2010 at 10:06 am

    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
    IPADDR=IP.OF.GUEST.ETH1
    NETMASK%5.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
    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%5.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%5.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
  • Mathieu Baudier at Aug 13, 2010 at 10:47 am

    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
    HWADDR3: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!
  • Compdoc at Aug 13, 2010 at 10:13 am
    NETMASK%5.255.255.255?
  • Mathieu Baudier at Aug 13, 2010 at 10:48 am
    NETMASK%5.255.255.255?
    it surprised me as well first, but that is what OVH recommends and it
    works fine with virtual interfaces
  • Dennis J. at Aug 13, 2010 at 3:33 pm

    On 08/13/2010 04:48 PM, Mathieu Baudier wrote:
    NETMASK%5.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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcentos-virt @
categoriescentos
postedAug 13, '10 at 9:19a
activeAug 13, '10 at 3:33p
posts6
users4
websitecentos.org
irc#centos

People

Translate

site design / logo © 2022 Grokbase