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! :)
Here is what I had to do to get it to work:
I had to disable 802.1w on the trunk ports specifically (2/1 and 2/2) under the default vlan on both brocade switches.
So spanning-tree is enabled for the actual vlan 510 and the default vlan 50 is disabled on the two ports that go to the cisco switch.
Then everything started to work fine.
So now I have this in the configs on the brocades:
vlan 50 name DEFAULT-VLAN by port
spanning-tree 802-1w
spanning-tree 802-1w ethe 2/1 disable
vlan 50 name DEFAULT-VLAN by port
spanning-tree 802-1w
spanning-tree 802-1w ethe 2/2 disable
Not sure if this is recommended or not though.
Best Answer
A true oob port will have hardware and software changes that separate the traffic from the regular ports. However I have seen some oob ports that don't respect this and connect up the traffic as if they were regular ports. If you're expecting the oob port to not share the cpu and therefore be accessible during problems, then you're generally paying extra for that switch and not using a lower end model. You will simply have to test whatever brand/model you have to see it's behavior.
Of course you can use a regular port from the front of the switch as your oob management, but some companies can't afford losing even one port for this purpose. Most of the time the oob is abandoned and management is done inline across the trunk to a virtual interface. I mean if you have enough spare ports to use one exclusively for oob, then chances are you probably don't need oob at all and can just plug into the console port.
As for routing, in my experience, there is a special subnet used solely for oob and therefore routing is never needed. All the oob ports will be aggregated onto this subnet and a bastion host will be used to access anything on this subnet directly. So you don't need a "default" route, then you're sending traffic to a very small range of administrative hosts. A default route is meant to send traffic to the internet essentially, whereas your oob setup will have very specific and well defined hosts that will be accessing it. Therefore you can have a more specifically defined static route to send traffic out the oob.
The oob is not the same as a console port. Generally it's just a regular port in a physically different place on the switch and it's up to the software to keep the traffic separate. Again you get what you pay for and most of the time if the main switch is down, the oob is not much better. For the most part, the additional hassle of an oob setup is not worth it and the only time it made sense is when some manufacturing networks wanted total separation from the corporate networks. So you're not gaining much in terms of rescuing a down switch.