[c-nsp] FHRP's and STP

[Phil Mayers]

Ross Vandegrift wrote:
> On Tue, Nov 18, 2008 at 03:52:35PM +0000, Phil Mayers wrote:
>> Variations on the STP/FHRP problem have been discussed a number of times 
>> on this list.
>>
>> It ought to be reasonably trivial to make FHRP follow STP - make the 
>> standby group follow a numbered track object:
>>
>> track 10 stub-object
>> int VlanXX
>>   standby prio [100 for slave | 101 for master]
>>   standby track 10 10
>>   standby preempt
>>
>> ...the write a pretty simple EEM applet triggered on the relevant STP 
>> syslog messages, to parse the root/not-root status from:
>>
>> sh spanning-tree vlan XX summary | inc ^Root
>>
>> ...and down/up the stub track object.
>>
>> The problem is that STP is a deeply sub-optimal solution to many of the 
>> cases where this matters.
> 
> This seems awfully complicated, but I suppose could be the only way to
> do it if you don't use MSTP.
> 
> It's really trivial to do with MSTP and HSRP.  We have two gateway
> routers that run HSRP.  Odd VLANs are mapped to MSTi 1, even to MSTi 2.
> Switch 1 is root bridge for MSTi 1 and HSRP active for odd VLANs.
> Switch 2 is root bridge for MSTi 2 and HSRP active for even VLANs.
> 
> Works great if your gear supports MSTP correctly (which, admittedly, is
> not as much of a given as it should be these days...).

I don't really see what MSTP has to do with it. You can (and we do) do 
this with PVST, which has the added advantage of working through 
equipment that doesn't support PVST.

The discussion was about protecting against mis-configuration i.e. this 
is good:

master:

spanning-tree vlan 2 root primary
int Vlan2
   standby prio 103

slave:

spanning-tree vlan 2 root secondary
int Vlan2
   standby prio 100

...but getting the STP roots the wrong way round (or the standby prio) 
is sub-optimal.

The other way of looking at it, is that by following the STP state, you 
can ignore setting the HSRP prio completely - it just tracks the STP 
root status (which is often what you want)

Of course there are a number of other unrelated issues e.g. forcing 
correct selection of an IGMP querier and PIM designated forwarder, DHCP 
relays, return path asymmetry etc. which make the Extreme/Foundry 
alternatives more attractive - the standby just doesn't route the network.