Just to add a little more to this, even after tuning all the rstp timers down to their minimum I don't see any noticeable change. I still drop 1 packet between convergence. So I guess it's better to keep the default timers to keep cpu usage down if it doesn't really gain me anything to go lower. Anyone have an opinion on this?
On Wed, Mar 9, 2011 at 8:53 PM, marc abel <[email protected]> wrote: > I'm steadily improving the network from little/no redundancy to > complete redundancy. I have to pick my budget battles right now and > frankly there are a few other places I'd rather improve first. > Fortunately all my server switches are linked via ether-channel. > Although no matter how many links in your bundle, if you lose your STP > root, then you are going to have a re-convergence. I had a core switch > roll over on me due to a "parity error" (according to TAC) a few > months ago. Things recovered really well, but I haven't implemented > the voice yet so I didn't have anything quite that latency dependent > at the time. > > On Wed, Mar 9, 2011 at 8:38 PM, Jay Taylor <[email protected]> wrote: >> Any chance of just doubling your links for each path? That would only >> require 2 extra pairs of fiber to each IDF rather than uplinking each >> switch. But then again, that 1 ping missed with RSTP was with default timers >> and I'm sure you could trim that down. >> >> >> On Wed, Mar 9, 2011 at 9:32 PM, Michael Smith <[email protected]> wrote: >>> >>> Well you guys are right. I've always dealt with switches that have been >>> etherchannelled to another switch so I never really dealt with switches that >>> are single linked like that. I just don't know the reason why anybody >>> wouldn't etherchannel their switches together. Hey I guess you live and you >>> learn! >>> >>> >>> >>> > Date: Wed, 9 Mar 2011 20:28:21 -0600 >>> > Subject: Re: [OSL | CCIE_RS] Rapid Spanning Tree convergence times >>> > From: [email protected] >>> > To: [email protected] >>> > CC: [email protected]; [email protected] >>> > >>> > Right because in my situation one of the links to the cores is going >>> > to be in blocking state. I don't see any way around that. >>> > >>> > On Wed, Mar 9, 2011 at 8:25 PM, Jay Taylor <[email protected]> wrote: >>> > > Even with HSRP and sub-second hellos you could lose pings depending on >>> > > how >>> > > STP needed to converge. >>> > > >>> > > On Wed, Mar 9, 2011 at 9:24 PM, Michael Smith <[email protected]> >>> > > wrote: >>> > >> >>> > >> Well I'm talking as far as the VOIP phones go. They obviously need a >>> > >> gateway and to not miss any pings you can always turn on HSRP. >>> > >> I'm not saying HSRP has anything to do with spanning tree. Just >>> > >> thinking >>> > >> about the fact of not losing any pings. >>> > >> >>> > >> >>> > >> >>> > >> ________________________________ >>> > >> Date: Wed, 9 Mar 2011 21:05:04 -0500 >>> > >> Subject: Re: [OSL | CCIE_RS] Rapid Spanning Tree convergence times >>> > >> From: [email protected] >>> > >> To: [email protected] >>> > >> CC: [email protected]; [email protected] >>> > >> >>> > >> Maybe I'm missing something but how can HSRP (or first hop redundancy >>> > >> protocol) replace STP/Etherchannel? Even if 2 of the Catalyst >>> > >> switches in >>> > >> that topology were L3 gateways and ran HSRP you still need to deal >>> > >> with the >>> > >> L2 loop that exists. >>> > >> >>> > >> >>> > >> On Wed, Mar 9, 2011 at 8:50 PM, [email protected] >>> > >> <[email protected]> >>> > >> wrote: >>> > >> >>> > >> Well if yor timers are that bad for VOIP you can always use hsrp if >>> > >> you >>> > >> don't want to use the etherchannel option. You can tune hsrp down to >>> > >> milliseconds if you wanted to. Of course your distribution switches >>> > >> need to >>> > >> support an enhanced IOS image >>> > >> >>> > >> Sent from my Verizon Wireless Phone >>> > >> >>> > >> ----- Reply message ----- >>> > >> From: "Jay Taylor" <[email protected]> >>> > >> Date: Wed, Mar 9, 2011 7:57 pm >>> > >> Subject: [OSL | CCIE_RS] Rapid Spanning Tree convergence times >>> > >> To: "marc abel" <[email protected]> >>> > >> Cc: <[email protected]> >>> > >> >>> > >> >>> > >> Enable portfast on the host ports and you'll see a much quicker >>> > >> transition. >>> > >> Just labbed this up and with portfast enabled I lost a single ping >>> > >> during >>> > >> the failover. Without it enabled I lost 12. >>> > >> >>> > >> For the VoIP question - in production I'd recommend building with >>> > >> Etherchannels just so STP never needs to converge. >>> > >> >>> > >> >>> > >> On Wed, Mar 9, 2011 at 5:41 PM, marc abel <[email protected]> wrote: >>> > >> >>> > >> > I have 4 switches connected in a loop. >>> > >> > >>> > >> > Cat1-------------Cat2 >>> > >> > | | >>> > >> > | | >>> > >> > Cat3----------Cat4 >>> > >> > >>> > >> > >>> > >> > Cat 1 is the root, Cat 2 is the secondary root. All the switches >>> > >> > are >>> > >> > set to RPVSTP and I have confirmed that show spanning-tree shows >>> > >> > RSTP >>> > >> > as the protocol. Cat 4 shows it's interface to cat3 as it's root >>> > >> > port >>> > >> > and the interface to Cat3 as the Alternate. I have not tuned any >>> > >> > timers. >>> > >> > >>> > >> > What should be the convergence time in this situation? >>> > >> > >>> > >> > If I run a ping from a host attached to Cat4 to a host attached to >>> > >> > Cat1 and then I shut the Cat1-Cat3 interface (on the Cat1 side) it >>> > >> > takes about 32 seconds before pings pick back up. I thought RSTP >>> > >> > was >>> > >> > supposed to converge in about 6 seconds? >>> > >> > >>> > >> > Another question, what is the fastest recovery time we can tune >>> > >> > down >>> > >> > to from RSTP? How do others tune this for VOIP? I know that I can >>> > >> > get >>> > >> > sub second convergence from OSPF but not all my switches have an >>> > >> > appropriate image to run ospf. >>> > >> > >>> > >> > >>> > >> > Thanks in advance. >>> > >> > >>> > >> > Marc >>> > >> > _______________________________________________ >>> > >> > For more information regarding industry leading CCIE Lab training, >>> > >> > please >>> > >> > visit www.ipexpert.com >>> > >> > >>> > >> _______________________________________________ >>> > >> For more information regarding industry leading CCIE Lab training, >>> > >> please >>> > >> visit www.ipexpert.com >>> > >> >>> > >> >>> > >> >>> > >> >>> > > >>> > > >> >> > _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
