Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot find an IP address to use for interface. #445

Closed
Herr-Herner opened this issue Oct 17, 2016 · 7 comments
Closed

Cannot find an IP address to use for interface. #445

Herr-Herner opened this issue Oct 17, 2016 · 7 comments

Comments

@Herr-Herner
Copy link

Herr-Herner commented Oct 17, 2016

I have migrated from Keepalived 1.2.19 to 1.2.23. Now I get the following exception:
(vi-cloud-gateway): Cannot find an IP address to use for interface eth4

This is my configuration on os-controller01:

global_defs {
    router_id os-haproxy01
}

vrrp_instance vi-cloud-gateway {
    state MASTER
    interface eth4
    virtual_router_id 52
    priority 101
    virtual_ipaddress {
        10.30.216.254/24 dev eth4
    }
    unicast_peer {
        10.30.200.102
    }
}

and on os-controller02:

global_defs {
    router_id os-haproxy02
}

vrrp_instance vi-cloud-gateway {
    state BACKUP
    interface eth4
    virtual_router_id 52
    priority 100
    virtual_ipaddress {
        10.30.216.254/24 dev eth4
    }
    unicast_peer {
        10.30.200.101
    }
}
root@os-controller01:~# ifconfig
eth4      Link encap:Ethernet  HWaddr 00:50:56:8d:d9:2c
          inet6 addr: fe80::250:56ff:fe8d:d92c/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:109 errors:0 dropped:5 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:6540 (6.5 KB)  TX bytes:648 (648.0 B)

root@os-controller02:~# ifconfig
eth4      Link encap:Ethernet  HWaddr 00:50:56:8d:61:8d
          inet6 addr: fe80::250:56ff:fe8d:618d/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:94 errors:0 dropped:2 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:5640 (5.6 KB)  TX bytes:648 (648.0 B)

What is wrong with my configuration or am I facing a bug?

@pqarmitage
Copy link
Collaborator

See 37488e57 for the commit that added this message.

The reason you are getting the message is that eth4 has no IP address configured on it. This means that keepalived doesn't know what source IP address to use when sending VRRP packets.

Your configuration appears to suggest that on os-controller01 should have IP address 10.30.200.101 on eth4, and on os-controller02 should have IP address 10.30.200.102 on eth4, but the ifconfig output shows that the interfaces don't have any IP addresses configured on them. This means that not only cannot keepalived determine what IP address to use as a source address, but if a VRRP packet were sent, it wouldn't be received by the other system.

@Herr-Herner
Copy link
Author

Herr-Herner commented Oct 18, 2016

I am sorry, it is better to provide you a full overview over the interfaces of each host. The ip addresses 10.30.200.101 and 10.30.200.102, respectively are each assigned to eth0 of the corresponding host:

root@os-controller01:~# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:50:56:8d:0d:34
          inet addr:10.30.200.101  Bcast:10.30.207.255  Mask:255.255.248.0
          inet6 addr: fe80::250:56ff:fe8d:d34/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1605484 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1703480 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:161590802 (161.5 MB)  TX bytes:1070865383 (1.0 GB)

eth1      Link encap:Ethernet  HWaddr 00:50:56:8d:7b:61
          inet addr:10.116.0.101  Bcast:10.116.15.255  Mask:255.255.240.0
          inet6 addr: fe80::250:56ff:fe8d:7b61/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:955 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:57300 (57.3 KB)  TX bytes:648 (648.0 B)

eth2      Link encap:Ethernet  HWaddr 00:50:56:8d:2f:d4
          inet addr:10.30.216.101  Bcast:10.30.216.255  Mask:255.255.255.0
          inet6 addr: fe80::250:56ff:fe8d:2fd4/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:298715 errors:0 dropped:5 overruns:0 frame:0
          TX packets:275512 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:337734808 (337.7 MB)  TX bytes:27619703 (27.6 MB)

eth3      Link encap:Ethernet  HWaddr 00:50:56:8d:67:3e
          inet6 addr: fe80::250:56ff:fe8d:673e/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:921468 errors:0 dropped:112966 overruns:0 frame:0
          TX packets:358 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:559527193 (559.5 MB)  TX bytes:15348 (15.3 KB)

eth4      Link encap:Ethernet  HWaddr 00:50:56:8d:d9:2c
          inet6 addr: fe80::250:56ff:fe8d:d92c/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3817 errors:0 dropped:2 overruns:0 frame:0
          TX packets:57857 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:230726 (230.7 KB)  TX bytes:3104526 (3.1 MB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:1125419 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1125419 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1
          RX bytes:65675371 (65.6 MB)  TX bytes:65675371 (65.6 MB)
root@os-controller02:~# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:50:56:8d:78:91
          inet addr:10.30.200.102  Bcast:10.30.207.255  Mask:255.255.248.0
          inet6 addr: fe80::250:56ff:fe8d:7891/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1426535 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1490942 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:114906058 (114.9 MB)  TX bytes:149478303 (149.4 MB)

eth1      Link encap:Ethernet  HWaddr 00:50:56:8d:07:96
          inet addr:10.116.0.102  Bcast:10.116.15.255  Mask:255.255.240.0
          inet6 addr: fe80::250:56ff:fe8d:796/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:944 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:56640 (56.6 KB)  TX bytes:648 (648.0 B)

eth2      Link encap:Ethernet  HWaddr 00:50:56:8d:40:b6
          inet addr:10.30.216.102  Bcast:10.30.216.255  Mask:255.255.255.0
          inet6 addr: fe80::250:56ff:fe8d:40b6/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:105147 errors:0 dropped:5 overruns:0 frame:0
          TX packets:12183 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:66674862 (66.6 MB)  TX bytes:1314121 (1.3 MB)

eth3      Link encap:Ethernet  HWaddr 00:50:56:8d:2d:e1
          inet6 addr: fe80::250:56ff:fe8d:2de1/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:231395 errors:0 dropped:113041 overruns:0 frame:0
          TX packets:24 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:76011854 (76.0 MB)  TX bytes:1320 (1.3 KB)

eth4      Link encap:Ethernet  HWaddr 00:50:56:8d:61:8d
          inet6 addr: fe80::250:56ff:fe8d:618d/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2199 errors:0 dropped:2 overruns:0 frame:0
          TX packets:22 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:131940 (131.9 KB)  TX bytes:1236 (1.2 KB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:1078057 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1078057 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1
          RX bytes:57626391 (57.6 MB)  TX bytes:57626391 (57.6 MB)

Can I tell VRRP to use 10.30.200.101 or 10.30.200.102, respectively as source address?

@pqarmitage
Copy link
Collaborator

To specify the source addresses, use the unicast_src_ip option.

I'm not entirely sure how you want this setup to work, but I'll have a guess.

I think you want to send and receive the VRRP adverts on eth0, but you want to add the virtual IP address 10.30.216.254/24 to eth4.

If that is the case, then I think you should change the configuration to have interface eth0. This will make the VRRP adverts go over eth0, and you have already specified that the VIPs are to be added to eth4.

@Herr-Herner
Copy link
Author

Herr-Herner commented Oct 18, 2016

Thanks for the hint. I have simplified my keepalived.conf on both hosts. Actually, I was not aware that the virtual_ipaddress block can contain addresses that should be assigned to other interfaces.

Is this a feasible solution?

os-controller01:

global_defs {
    router_id os-haproxy01
}

vrrp_script check-haproxy {
    script "killall -0 haproxy"
    interval 2
}

vrrp_instance vi-cloud {
    state MASTER
    interface eth0
    virtual_router_id 50
    priority 101
    virtual_ipaddress {
        10.30.200.99/21  dev eth0 label eth0:0
        10.30.200.100/21 dev eth0 label eth0:1
        10.30.216.100/24 dev eth2 label eth2:0
        10.30.216.254/24 dev eth4
    }
    unicast_peer {
        10.30.200.102
    }
    track_interface {
        eth0
        eth2
        eth4
    }
    track_script {
        check-haproxy
    }
}

os-controller02:

global_defs {
    router_id os-haproxy02
}

vrrp_script check-haproxy {
    script "killall -0 haproxy"
    interval 2
}

vrrp_instance vi-cloud {
    state BACKUP
    interface eth0
    virtual_router_id 50
    priority 100
    virtual_ipaddress {
        10.30.200.99/21  dev eth0 label eth0:0
        10.30.200.100/21 dev eth0 label eth0:1
        10.30.216.100/24 dev eth2 label eth2:0
        10.30.216.254/24 dev eth4
    }
    unicast_peer {
        10.30.200.101
    }
    track_interface {
        eth0
        eth2
        eth4
    }
    track_script {
        check-haproxy
    }
}

@pqarmitage
Copy link
Collaborator

The configuration looks reasonable to me.

You might want to consider adding unicast_src_ip entries to ensure it always used the source ip address that you want (ie. 10.30.200.101 or 102).

You don't need eth0 in the track_interface block, since it will do that automatically for the configured interface.

You also don't need to specify dev eth0 for the virtual ipaddresses that are on eth0 (since it defaults to the interface entry), but you do need the dev eth2 and dev eth4.

I would remove the /21s for the addresses on eth0, and the /24 for the IP addresses in eth2, since those networks are already configured, and all you are wanting to do is add the individual addresses. For the eth4 VIPs, you do need the /24s since the network isn't already configured, and it might we worth adding brd 10.30. 216.255 to those lines to ensure you get the broadcast address you want.

You could increase the priorities to say, 240 and 250, which will result in (slightly) faster transitions times to master.

@Herr-Herner
Copy link
Author

Thank you very much for feedback. That was really helpful! I have integrated your suggestions resulting in the following configurations.

os-controller01:

global_defs {
    router_id os-haproxy01
}

vrrp_script check-haproxy {
    script "killall -0 haproxy"
    interval 2
}

vrrp_instance vi-cloud {
    state MASTER
    interface eth0
    virtual_router_id 50
    priority 250
    virtual_ipaddress {
        10.30.200.99  label eth0:0
        10.30.200.100 label eth0:1
        10.30.216.100 dev eth2 label eth2:0
        10.30.216.254/24 brd 10.30.216.255 dev eth4
    }
    unicast_src_ip 10.30.200.101
    unicast_peer {
        10.30.200.102
    }
    track_interface {
        eth2
        eth4
    }
    track_script {
        check-haproxy
    }
}

os-controller02:

global_defs {
    router_id os-haproxy02
}

vrrp_script check-haproxy {
    script "killall -0 haproxy"
    interval 2
}

vrrp_instance vi-cloud {
    state BACKUP
    interface eth0
    virtual_router_id 50
    priority 240
    virtual_ipaddress {
        10.30.200.99  label eth0:0
        10.30.200.100 label eth0:1
        10.30.216.100 dev eth2 label eth2:0
        10.30.216.254/24 brd 10.30.216.255 dev eth4
    }
    unicast_src_ip 10.30.200.102
    unicast_peer {
        10.30.200.101
    }
    track_interface {
        eth2
        eth4
    }
    track_script {
        check-haproxy
    }
}

@pqarmitage
Copy link
Collaborator

Glad to be able to help. I think the configuration looks spot on now.

I'll close this issue now, since I think it is all resolved, but you can still add new messages to it.

@pqarmitage pqarmitage reopened this Oct 18, 2016
openstack-gerrit pushed a commit to openstack/openstack that referenced this issue Aug 24, 2017
Project: openstack/neutron  f0e4809ca82628faa43d6ac83892b4451e1512f6

Fix test_keepalived_ipv6_support for Keepalived v1.2.20

In commit [1] (some explanation in [2] ) VRRP initialisation is enhanced
to read source IP address(to use when sending VRRP packets) from the
HA interface or from keepalived config("unicast_src_ip" parameter).
If it is unable to find IP address, VRRP initialisation will fail with
error "Cannot find an IP address to use for interface".

In the test, we set vrrp->family to AF_INET by setting vip to
169.254.0.1/24 through config, but not providing source IPv4 address(i.e
no 'unicast_src_ip' option or no IP on HA interface), making the test
to fail with [1]. To fix that, we set the IP address on HA interface.

Note: Commit [1] is added in Keepalived version 1.2.20.
Tested the fix on both Keepalived v1.2.19 and Keepalived v1.2.20.

[1] acassen/keepalived@37488e57
[2] acassen/keepalived#445

Closes-bug: #1712388
Change-Id: I260c0e6810ed54c93f93621afa6ab13855ef2428
openstack-gerrit pushed a commit to openstack/neutron that referenced this issue Aug 24, 2017
In commit [1] (some explanation in [2] ) VRRP initialisation is enhanced
to read source IP address(to use when sending VRRP packets) from the
HA interface or from keepalived config("unicast_src_ip" parameter).
If it is unable to find IP address, VRRP initialisation will fail with
error "Cannot find an IP address to use for interface".

In the test, we set vrrp->family to AF_INET by setting vip to
169.254.0.1/24 through config, but not providing source IPv4 address(i.e
no 'unicast_src_ip' option or no IP on HA interface), making the test
to fail with [1]. To fix that, we set the IP address on HA interface.

Note: Commit [1] is added in Keepalived version 1.2.20.
Tested the fix on both Keepalived v1.2.19 and Keepalived v1.2.20.

[1] acassen/keepalived@37488e57
[2] acassen/keepalived#445

Closes-bug: #1712388
Change-Id: I260c0e6810ed54c93f93621afa6ab13855ef2428
openstack-gerrit pushed a commit to openstack/neutron that referenced this issue Aug 26, 2017
In commit [1] (some explanation in [2] ) VRRP initialisation is enhanced
to read source IP address(to use when sending VRRP packets) from the
HA interface or from keepalived config("unicast_src_ip" parameter).
If it is unable to find IP address, VRRP initialisation will fail with
error "Cannot find an IP address to use for interface".

In the test, we set vrrp->family to AF_INET by setting vip to
169.254.0.1/24 through config, but not providing source IPv4 address(i.e
no 'unicast_src_ip' option or no IP on HA interface), making the test
to fail with [1]. To fix that, we set the IP address on HA interface.

Note: Commit [1] is added in Keepalived version 1.2.20.
Tested the fix on both Keepalived v1.2.19 and Keepalived v1.2.20.

[1] acassen/keepalived@37488e57
[2] acassen/keepalived#445

Closes-bug: #1712388
Change-Id: I260c0e6810ed54c93f93621afa6ab13855ef2428
(cherry picked from commit 334a1ed)
openstack-gerrit pushed a commit to openstack/neutron that referenced this issue Aug 26, 2017
In commit [1] (some explanation in [2] ) VRRP initialisation is enhanced
to read source IP address(to use when sending VRRP packets) from the
HA interface or from keepalived config("unicast_src_ip" parameter).
If it is unable to find IP address, VRRP initialisation will fail with
error "Cannot find an IP address to use for interface".

In the test, we set vrrp->family to AF_INET by setting vip to
169.254.0.1/24 through config, but not providing source IPv4 address(i.e
no 'unicast_src_ip' option or no IP on HA interface), making the test
to fail with [1]. To fix that, we set the IP address on HA interface.

Note: Commit [1] is added in Keepalived version 1.2.20.
Tested the fix on both Keepalived v1.2.19 and Keepalived v1.2.20.

[1] acassen/keepalived@37488e57
[2] acassen/keepalived#445

Closes-bug: #1712388
Change-Id: I260c0e6810ed54c93f93621afa6ab13855ef2428
(cherry picked from commit 334a1ed)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants