Keepalived router on virtual ip is not reachable

keepalivedrouting

I've setup keepalived to manage a virtual ip between two hosts.

My setup is the following

Server #1: Hostname folmer, ip 192.168.0.1/22 dev p2p1
Server #2: Hostname flemming, ip 192.168.0.2/22 dev p2p1
VIP: 192.168.0.3/22

Keepalived is working and the VIP is switched between the servers when one goes down.

Problem: On the local network I can ping 192.168.0.3, but when I set my default route to 192.168.0.3 instead of 192.168.0.1, I can no longer reach the internet through server #1.

Keepalived conf on server #1:

global_defs {
    notification_email {
        [SNIP]
        [SNIP]
    }
    notification_email_from [SNIP]
    smtp_server 127.0.0.1
    smtp_connect_timeout 30
    router_id folmer
}
vrrp_instance VI_1 {
    state MASTER
    interface p2p1
    virtual_router_id 52
    priority 150
    advert_int 1
    garp_master_delay 2
    smtp_alert
    authentication {
        auth_type PASS
        auth_pass [SNIP]
    }
    virtual_ipaddress {
        192.168.0.3 label p2p1:0
    }
}

server #1 ip's:

p2p1      Link encap:Ethernet  HWaddr 00:0a:f7:40:d7:5f  
          inet addr:192.168.0.1  Bcast:192.168.3.255  Mask:255.255.252.0
          inet6 addr: fe80::20a:f7ff:fe40:d75f/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:11446972 errors:0 dropped:0 overruns:0 frame:0
          TX packets:11382043 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:5461610409 (5.4 GB)  TX bytes:9274459351 (9.2 GB)
          Interrupt:16 

p2p1:0    Link encap:Ethernet  HWaddr 00:0a:f7:40:d7:5f  
          inet addr:192.168.0.3  Bcast:0.0.0.0  Mask:255.255.255.255
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Interrupt:16

Edit

Still not wokring as needed. Routing is configured and it is working, as long as the clients use the IP 192.168.0.1 as the gateway instead of 192.168.0.1. Obviously I want it to work with 192.168.0.3.

Best Answer

I guess that

ip addr show | grep global

will show that your virtual address is

192.168.0.3/32

/32 is usually not the desired result, therefore you should add e.g. /24:

virtual_ipaddress {
  192.168.0.3/24 label p2p1:0
}

Related Solutions

Openvpn for client/server in same subnet

Your default route metric value is lower than the 10.22.0.0/16 route and it gets routed to the default route. In resolving routes, if more than one route matches destination, the lower metric value route takes precedence.

Either push a default route through VPN or lower metric for 10.22.0.0/16 (increase metric for default route).

It should look like this:

Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
      0.0.0.0          0.0.0.0    192.168.1.254     192.168.1.23    1000
    10.22.0.0      255.255.0.0        10.22.8.1       10.22.8.10     30
    10.22.8.0    255.255.255.0         On-link        10.22.8.10    286
   10.22.8.10  255.255.255.255         On-link        10.22.8.10    286
  10.22.8.255  255.255.255.255         On-link        10.22.8.10    286

Centos 6.2 Fresh ‘Basic Server’ install networking issues

Your routes and configuration look fine.

$: route -n
Destination // Gateway // Genmask // Flags // Metric // Ref // Use // Iface
66.*.*.0       0.0.0.0    255.255.255.248   U   1003      0   0     0  em2
0.0.0.0        66.*.*.1   0.0.0.0           UG     0      0   0     0  em2

The first route, 66.*.*.0/29 with gateway 0.0.0.0 tells your computer to use interface em2 and then make an arp request to find the hardware address of the host you're trying to reach. This is a "connected" route.

The second one is the default route, pointing at your default gateway through em2. If you need to send a packet in another network than 66.*.*.0/29, your computer will make an arp request to find 66.*.*.1 and then send the packets to it.

The only thing in your configuration that could be an issue is the NM_CONTROLLED=yes statement in /etc/sysconfig/network-scripts/ifcfg-em2. This tells the system that this interface is controlled by NetworkManager. This could interfere with your static configuration.

However, even without any default gateway you should be able to ping and ssh from the 66.*.*.0/29 subnet to your machine.

Check layer 1 first, and ensure that the cable is plugged on each side. Use leds on nic and switch, and check if the system sees it correctly:

# mii-tool
eth0: negotiated 1000baseT-FD flow-control, link ok

Then verify if any iptables are dropping the packets. Use iptables -L or iptables-save to check for any rules, and iptables -D <rule> to delete them. Pay attention to the default policy.

Also, on some systems, NetworkManager can configure ufw automatically, and I've had issues with static interface configuration that wasn't seen by NM and hence blocked by ufw.