VRRP not receiving traffic (lab)

[scottikon]

Hoping someone might have some inspiration and point out an obvious thing I am doing wrong. 

I am going to be doing some work for a customer soon where I will be deploying an active/active VRRP cluster with 2 x VRIDs for each interface. So for each VRID in each subnet, FW1 will be master for one VRID and FW2 will be master for the second VRID. 

I am labbing this up so I am more familiar with VRRP as it's been a while and I have a very simple lab. 

R77.30.03 Management Server in VM (10.255.95.1)

Windows Server VM (10.255.35.66)

FW1 (R77.30)

FW2 (R77.30)

I have configured VRRP monitored circuit with FW1 as priority 100 and FW2 with priority 95. I just want to get basic HA working for now in the lab. 

If I run show vrrp summary, I can see that FW1 is master for all the interfaces and FW2 is backup. From the windows server, I can ping the individual interfaces on the firewalls but not the VIP. I have the VIP set as the default gateway for the windows server and I am unable to reach beyond the firewall and i do not see the traffic in the logs or on a tcpdump. The windows server is resolving the MAC address for the backup gateway address.

I have attached a visio to illustrate. 

If anyone has got any ideas I would be very greatful. 

[Maarten_Sjouw]

Why are you using 2 VRID's, I dont see them being used in your lab drawing, also why are you using interface commands in the definition of the vips?
You would only be able to use 2 VRID's when you have 2 completely separated traffic flows, like eth1 to/from eth2 and eth3 to/from eth4. Otherwise traffic will start hopping members and being dropped as you also did not enable Sate Sync.
Active/active is really not something you would want to do anyway.
I would just use simplified VRRP.

[scottikon]

Afternoon, 

I agree, if I was designing the solution this is not something I would recommend. 

I am a lot further on than I was yesterday now, which is good and here is my findings: -

• the lab environment I was using doesn't seem to like Multicast MAC addresses mapped to unicast IP addresses so would not forward traffic to the gateway. As soon as I changed the VMAC mode to interface where it uses the master's interface MAC for the backup gateway address then it sprung into life;
• by disabling "drop out of state packets" I am able to ping from one subnet to another despite which VRID the device is using for it's default gateway as long as NAT is not involved;
• because the NAT tables are not synchronised in this deployment, traffic sourced from a VRID that is master on 1 gateway has to be natted behind the IP address for the external interface in the same VRID. Otherwise return traffic would hit the other gateway and without syncrhonised NAT tables, it will just drop the traffic;

So although we wouldn't recommend it and there are constraints, we can make it work as insisted by the customer.