# Problem with VRRP-A and Virtual Server IP (VIP) **URL:** \ **Category:** ADC - Application Delivery\ **Tags:** vrrp-a-ha, virtual-server-vip\ **Created:** [February 20, 2020, 3:16pm UTC](https://community.a10networks.com/t/problem-with-vrrp-a-and-virtual-server-ip-vip/591 "2020-02-20T15:16:34Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![REDES\_STI\_UCHILE](https://avatars.discourse-cdn.com/v4/letter/r/d6d6ee/32.png) [@REDES\_STI\_UCHILE](https://community.a10networks.com/u/REDES_STI_UCHILE)\ **Post date:** [February 20, 2020, 3:16pm UTC](https://community.a10networks.com/t/problem-with-vrrp-a-and-virtual-server-ip-vip/591/1 "2020-02-20T15:16:34Z")
Hi everyone: We have a problem with our Thunder 930 cluster (two A10 Thunder 930 in a L3V scenario with VRRP-A and VCS). There are some partitions created on the cluster and we are seeing a strange behaviour when we change the priority of VRRP-A in any of this partitions. When we decrease the priority of VRRP-A on an active partition, the MAC address of the floatings IP’s changes correctly to the standby device, and communication to the server side and to the upstream router works fine. But, Virtual Server IP’s (VIPs) stop working.  This means that below the custer everyting is ok as wells as upstream, but no communication or service can be established thourgh the VIP’s. We see that the packets with destination to any of the VIPs, are routed-back to the upstream router by the new active device. Obviously, the upstream router send again packets to the active device, creating a L3 loop. However, if instead of decreasing the priority, we shutdown all interfaces on the active device (or shutdown the actual active device), then the failover to standby device occurs and everything works OK (including VIPs). We have 4.1.1-P6 (build 62) version in both devices. Last upgrade done in 2018 from 2.7.1-GR1 (build 58) to the running one. Has anyone had a behavior similar to this? Below is an example of configuring one of the problem partitions. ![a10 scenario.PNG](https://us1.discourse-cdn.com/flex002/uploads/a10_community/original/1X/4f4c92a35efb004fee0d9e35969740b423e3a1aa.png) interface ve 1/201   name SERVER-SIDE   ip address 10.10.10.2 255.255.255.0  ! interface ve 1/301   name UPSTREAM  ip address 20.20.20.2 255.255.255.0  ! interface ve 2/201   name SERVER-SIDE  ip address 10.10.10.3 255.255.255.0  ! interface ve 2/301   name UPSTREAM  ip address 20.20.20.3 255.255.255.0 vlan 1/201   tagged trunk 10  router-interface ve 201   name SERVER-SIDE !     vlan 1/301   tagged trunk 10  router-interface ve 301   name UPSTREAM !     vlan 2/201   tagged trunk 9  router-interface ve 201   name SERVER-SIDE !     vlan 2/301   tagged trunk 9  router-interface ve 301   name UPSTREAM vrrp-a vrid 5   floating-ip 10.10.10.1   floating-ip 20.20.20.1   device-context 1   blade-parameters     priority 200     tracking-options      vlan 301 timeout 5 priority-cost 100      vlan 201 timeout 5 priority-cost 100   device-context 2   blade-parameters     priority 150     tracking-options      vlan 301 timeout 5 priority-cost 100      vlan 201 timeout 5 priority-cost 100 device-context 1  ip route 0.0.0.0 /0 20.20.20.20  ! device-context 2  ip route 0.0.0.0 /0 20.20.20.20 Thanks in advance ---
**Author:** ![mdunn](https://avatars.discourse-cdn.com/v4/letter/m/87869e/32.png) [@mdunn](https://community.a10networks.com/u/mdunn)\ **Post date:** [February 24, 2020, 4:42pm UTC](https://community.a10networks.com/t/problem-with-vrrp-a-and-virtual-server-ip-vip/591/2 "2020-02-24T16:42:39Z")
Hello - This is an interesting scenario… One thought that comes to mind - I see you’re using VRID 5 for VRRP. Do you have vrid 5 assigned to the VIPs that fail to failover? ```yaml slb virtual-server test 192.168.1.20 vrid 5 ``` Mike ---
**Author:** ![REDES\_STI\_UCHILE](https://avatars.discourse-cdn.com/v4/letter/r/d6d6ee/32.png) [@REDES\_STI\_UCHILE](https://community.a10networks.com/u/REDES_STI_UCHILE)\ **Post date:** [February 25, 2020, 7:49pm UTC](https://community.a10networks.com/t/problem-with-vrrp-a-and-virtual-server-ip-vip/591/3 "2020-02-25T19:49:49Z")
First of all, thank’s for your reply, Mike. About your suggestion, we don´t have that command in the virtual-server configuration. When we try to configure it, we receive this error: ```yaml "You are trying to change the vrid of virtual server with nat pool on it, please delete nat pool first !" ``` We use source-nat in our L3V scenario because servers in that partition need to reach virtual servers (VIPs) in the same partition. So, we try to remove the NAT configuration first, then configure “vrid xx” on virtual-server and then configure again the NAT, but we receive this error: ```yaml "Invalid HA ID specified." ``` Using the same image from the last post, this is an example of one of our slb configurations. slb server server-01 10.10.10.5   port 443 tcp slb server server-02 10.10.10.6   port 443 tcp slb service-group SG-test\_443 tcp   method least-connection   extended-stats   member server-01 443   member server-02 443 slb virtual-server VIP-test 30.30.30.10  extended-stats  port 443 tcp   ha-conn-mirror   extended-stats   access-list 100 source-nat-pool source\_nat   service-group SG-test\_443 access-list 100 remark acl\_source\_nat access-list 100 permit ip 20.20.20.0 0.0.0.255 any ip nat pool source\_nat 30.30.30.254 30.30.30.254 netmask /24 What do you think is the mistake? Thank’s in advance… ---
**Author:** ![mdunn](https://avatars.discourse-cdn.com/v4/letter/m/87869e/32.png) [@mdunn](https://community.a10networks.com/u/mdunn)\ **Post date:** [February 26, 2020, 4:13pm UTC](https://community.a10networks.com/t/problem-with-vrrp-a-and-virtual-server-ip-vip/591/4 "2020-02-26T16:13:29Z")
In the instance of NAT pool, you will also need to set the VRID for the pool to match the VIP: ```yaml ip nat pool source_nat 30.30.30.254 30.30.30.254 netmask /24 vrid 4 ``` After that, you should be allowed to bind the pool to the vPort and test. Hope this helps! ---
**Author:** ![REDES\_STI\_UCHILE](https://avatars.discourse-cdn.com/v4/letter/r/d6d6ee/32.png) [@REDES\_STI\_UCHILE](https://community.a10networks.com/u/REDES_STI_UCHILE)\ **Post date:** [April 17, 2020, 2:41pm UTC](https://community.a10networks.com/t/problem-with-vrrp-a-and-virtual-server-ip-vip/591/5 "2020-04-17T14:41:05Z")
, thanks for your reply. Indeed, when we applied the command you suggested, the VIPs “switched” from the active context to standby. according to VRRP status. However, this causes all traffic to the VIPs to be “nated”, changing the source IP of all packets. Our intention was that “source-NAT” would only be applied when a server in a context wanted to query a VIP of the same context. In other words (using the example above), that the source-NAT is applied only when a server with IP 10.10.10.x needs to access a VIP 30.30.30.x. When other IPs query the VIP, we don’t want “source-nat” to apply. Is there any possibility of doing both? That the VIPs switch to standby according to the VRRP, but that the source-nat is applied to a group of source IPs, but not to all the packets that reach the VIP. Thank’s in advance… ---
**Author:** ![mdunn](https://avatars.discourse-cdn.com/v4/letter/m/87869e/32.png) [@mdunn](https://community.a10networks.com/u/mdunn)\ **Post date:** [April 17, 2020, 3:18pm UTC](https://community.a10networks.com/t/problem-with-vrrp-a-and-virtual-server-ip-vip/591/6 "2020-04-17T15:18:27Z")
Strange, I would expect the “access-list 100 source-nat-pool source\_nat” config under the vPort to function the same regardless of the vrid assignment for the VIP. Would you mind sharing the current config of the VIP? ---
**Author:** ![REDES\_STI\_UCHILE](https://avatars.discourse-cdn.com/v4/letter/r/d6d6ee/32.png) [@REDES\_STI\_UCHILE](https://community.a10networks.com/u/REDES_STI_UCHILE)\ **Post date:** [April 20, 2020, 5:16pm UTC](https://community.a10networks.com/t/problem-with-vrrp-a-and-virtual-server-ip-vip/591/7 "2020-04-20T17:16:00Z")
thank’s Using the same image from the previous post, this is an example of one of our slb configurations. ```yaml slb server server-01 10.10.10.5  ``` port 443 tcp ```yaml slb server server-02 10.10.10.6  ``` port 443 tcp ```yaml slb service-group SG-test_443 tcp   method least-connection   extended-stats   member server-01 443  ``` member server-02 443 ```yaml slb virtual-server VIP-test 30.30.30.10  extended-stats  port 443 tcp   ha-conn-mirror   extended-stats   access-list 100 source-nat-pool source_nat ``` service-group SG-test\_443 ```yaml access-list 100 remark acl_source_nat ``` access-list 100 permit ip 20.20.20.0 0.0.0.255 any ```yaml ip nat pool source_nat 30.30.30.254 30.30.30.254 netmask /24 ``` When we try to use “ip nat pool source\_nat 30.30.30.254 30.30.30.254 netmask / 24 vrid 4”, all traffic to the VIP is nated. But we need NAT only when a server in a context needs to reach a VIP on the same context. User traffic should not be nated. Any clue to what’s going on? ---
**Author:** ![mdunn](https://avatars.discourse-cdn.com/v4/letter/m/87869e/32.png) [@mdunn](https://community.a10networks.com/u/mdunn)\ **Post date:** [April 20, 2020, 8:27pm UTC](https://community.a10networks.com/t/problem-with-vrrp-a-and-virtual-server-ip-vip/591/8 "2020-04-20T20:27:22Z")
Hello, I tested this in my lab with version 4.1.4-GR1-P2 as well as 4.1.1-P12. In both scenarios, if the source IP missed the ACL, the traffic was not NAT’d. When I added the subnet of the source IP to the ACL, the traffic was NAT’d. Perhaps this is a bug with 4.1.1-P6, or there is something missing with your config. Here’s what I tested: ```yaml vrrp-a common   device-id 1   set-id 1   disable-default-vrid   enable ! vrrp-a vrid 4 ! ip nat pool test 192.168.1.2 192.168.1.2 netmask /32 vrid 4 ! access-list 100 permit ip 20.20.20.0 0.0.0.255 any ! access-list 100 permit ip 10.0.0.0 0.255.255.255 any <-- ACL I added / removed ! slb virtual-server act_l4_slb_vip 10.13.16.195   vrid 4   port 80 tcp     access-list 100 source-nat-pool test ``` service-group sg\_act\_l4\_slb\_vip\_80\_tcp Another thought that comes to mind is maybe you have some different settings within “slb common” which are interfering. ---
**Author:** ![huzhiqi](https://avatars.discourse-cdn.com/v4/letter/h/ccd318/32.png) [@huzhiqi](https://community.a10networks.com/u/huzhiqi)\ **Post date:** [April 30, 2020, 1:35am UTC](https://community.a10networks.com/t/problem-with-vrrp-a-and-virtual-server-ip-vip/591/9 "2020-04-30T01:35:34Z")
Maybe some issue.