This is the logical view of what you're trying to achieve:
Configure the router priorities for both VRRP 'a' and VRRP 'b' as follows:
- Router 1: 110 (master)
- Router 2: 100 (backup)
The configure interface tracking as follows:
- Router 1 VRRP a: track interface R1b with a track priority of 90
- Router 1 VRRP b: track interface R1a with a track priority of 90
- Router 2 VRRP a: track interface R2b with a track priority of 90
- Router 2 VRRP b: track interface R2a with a track priority of 90
If interface R1b goes down, Router 1 will change its VRRP 'a' priority to 90. This priority is now less than the VRRP 'a' priority that Router 2 has, so it will preempt and take over mastership for VRRP 'a'.
In addition, because interface R1b has gone down, then the VRRP hello packets will fail across VLAN 'b'. This will be detected by Router 2 (after failing to receive a hello packet within the dead timer interval), at which point it will take over mastership for VRRP 'b'.
If interface R1a goes down, then in a similar fashion, Router 2 will take over mastership for both VRRP groups (Router 1 VRRP 'b' priority = 90, and the VRRP hello packets will fail across VLAN 'a').
If either interface R2a or R2b goes down, then Router 1 will continue to be master for both VRRP groups.
Note that the priority value I've chosen above are quite arbitrary -- you may want to choose different values. Also, if the VIP address of a particular VRRP group is the same as the interface address for one of the routers in that VRRP group, then that router will automatically take a priority of 255 (i.e. it will always be the master unless that interface goes down).
As a side note, to get the above logical architecture, you will need a physical architecture similar to the following:
You can read up on VRRP on Wikipedia here:
http://en.wikipedia.org/wiki/Virtual_Router_Redundancy_Protocol
Brocade's VRRP documentation is here:
http://www.brocade.com/support/Product_Manuals/ServerIron_SwitchRouterGuide/VRRP.7.2.html
Brocade also have some VRRP configuration examples here:
http://www.brocade.com/support/Product_Manuals/ServerIron_SwitchRouterGuide/VRRP.7.11.html
Hope this helps! :)
Best Answer
You actually don't have to do anything. VPC paired Nexus work exactly as you want them to.
The prerequisite is that all systems involved (i.e. the servers) are attached to the Nexus over a VPC enabled port channel of that given Nexus pair.
https://community.cisco.com/t5/networking-documents/peer-gateway-feature-on-the-nexus-7000/ta-p/3113290
Please note: That post is actually about the
vpc peer gatewayfeature, which you don't usually need in normal circumstances. But in its first section, it also explains forwarding under normal circumstances (which apply to your case):Attempting to quote:
... and then the post goes to explain the corner case where you'd need vpc peer gateway.
There's a corollary that comes out of the Nexus' default behavior: Under regular operating conditions, there should never be high traffic volume on the VPC peer link (in extenso: "workload traffic") . If there is, the admin may want to check the VPC pair for config inconsistencies or verify the state of links to downstream or upstream switches or hosts. Chances are, that not all links are up.