5 minutes smells like an ARP cache timeout, so I'd start by watching
arp caches and mac-address tables, for clues.
make sure you are running the Foundry equivalent of PVST+ ( i.e. a
separate instance of STP per vlan, not a single common instance.
Probably MSTP ?)
tcpdump should tell you what is eventually triggering the changeover
event, and then you can work back from there.
Some bedtime reading suggestions: (Cisco, but theory is the same.)
http://www.cisco.com/application/pdf/paws/24062/146.pdf
http://www.cisco.com/application/pdf/paws/28943/170.pdf
http://www.cisco.com/en/US/tech/tk389/tk621/tsd_technology_support_troubleshooting_technotes_list.html
/Pete
On 26 Jan 2009, at 16:40, Jason Dixon wrote:
I'm attempting to setup a failover bridge(4) configuration with RSTP
for
rapid failover. At this point I'm still tweaking the bridges and
switches. We're using a Foundry LS648 for this test, so we don't have
Cisco's "uplinkFast" extension at our disposal.
We have two VLANs configured on the switch, each with 802.1w enabled
and
functioning normally. Plugged into each VLAN is a single client and
one
interface from each firewall.
10.20.0.2 <-> vlan200 <-> bridge0 <-> vlan300 <-> 10.20.0.3
Regardless of whether I use rstp (default) or stp (+ ifpriority/
ifcost)
on the bridges, it always takes ~5 minutes to failover. I noticed
that
with stp enabled on the physical interfaces, the switch would
immediately show the correct bridge as the forwarding root. With the
default rstp, the switch shows all ports as designated forwarding.
I've also tried disabling learning on the internal interfaces and
adding
static entries for 10.20.0.3, but this has no effect on the recovery
time.
Any suggestions on getting a rapid failover working?
Thanks,
--
Jason Dixon
DixonGroup Consulting
http://www.dixongroup.net/