A better allusion might be a branch swatting us in the face. I've never known a tree to bite.
On Wed, Sep 25, 2013 at 4:33 PM, Micheal Espinola Jr < [email protected]> wrote: > STP will never stop being something to bite us all in the ass... > > -- > Espi > > > > On Wed, Sep 25, 2013 at 12:56 PM, Kurt Buff <[email protected]> wrote: > >> Another not-quite-zombie thread update: >> >> After mucho packet capturing, and trying to figure stuff out myself, I >> called in the cavalry. >> >> I sent the packets for a small outbreak to an outside firm that I've >> used before, and they handed it to their packethead. >> >> It is/was an STP problem. Coming from the Cisco switches in the lab - >> there are several in there that are announcing they are the root >> bridge, and prod and dev switches ended up fighting. >> >> I've explained the problem to the director of engineering, and they've >> come up with a router and a couple of their own switches, and I'm in >> the process of migrating their address space/VLANs off of my equipment >> onto their router/switches. I've set up a /30 between the networks, >> and will be putting up routes pointing to the new connection as we >> migrate stuff off. >> >> BTW - I came across the following while doing some of the research - >> it's pretty good: >> http://www.cisco.com/image/gif/paws/10556/spanning_tree1.swf >> >> Kurt >> >> On Sun, Sep 22, 2013 at 7:05 PM, Micheal Espinola Jr >> <[email protected]> wrote: >> > C-D-A, yep yep. >> > >> > -- >> > Espi >> > >> > >> > >> > On Sun, Sep 22, 2013 at 6:56 PM, Kurt Buff <[email protected]> wrote: >> >> >> >> Well, I do remember reading a long time ago that traffic shouldn't go >> >> through more than three switches on a LAN (was that referred to as the >> >> diameter? I can't remember) - that pretty much matches the Cisco model >> >> of core, distribution and access, as described here, among many other >> >> places: >> >> >> http://searchnetworking.techtarget.com/tip/Core-Distribution-and-Access >> >> >> >> On Sun, Sep 22, 2013 at 6:33 PM, Micheal Espinola Jr >> >> <[email protected]> wrote: >> >> > Personally speaking, I try to stick to it as well. I've noticed more >> >> > wonky >> >> > things the more environments diverge from it. Technically speaking, >> >> > that >> >> > should not make sense - but this an unqualified opinion of mine. >> >> > >> >> > -- >> >> > Espi >> >> > >> >> > >> >> > >> >> > On Fri, Sep 20, 2013 at 11:59 AM, Michael B. Smith >> >> > <[email protected]> >> >> > wrote: >> >> >> >> >> >> I still use it. >> >> >> >> >> >> >> >> >> >> >> >> Violate the rule at your peril. :P >> >> >> >> >> >> >> >> >> >> >> >> From: [email protected] >> >> >> [mailto:[email protected]] On Behalf Of Jonathan Link >> >> >> >> >> >> >> >> >> Sent: Friday, September 20, 2013 2:07 PM >> >> >> >> >> >> >> >> >> To: [email protected] >> >> >> Subject: Re: [NTSysADM] Semi-OT: Network problem >> >> >> >> >> >> >> >> >> >> >> >> Is this the equivalent of Vader saying "Your powers are weak, old >> man" >> >> >> to >> >> >> Obi Wan? >> >> >> >> >> >> >> >> >> >> >> >> On Fri, Sep 20, 2013 at 1:55 PM, Kurt Buff <[email protected]> >> wrote: >> >> >> >> >> >> Sigh. Yes, but... >> >> >> >> >> >> "The 5-4-3 rule was created when 10BASE5 and 10BASE2 were the only >> >> >> types of Ethernet network available. The rule only applies to >> >> >> shared-access 10 Mbit/s Ethernet backbones. The rule does not apply >> to >> >> >> switched Ethernet because each port on a switch constitutes a >> separate >> >> >> collision domain." >> >> >> >> >> >> :) >> >> >> >> >> >> Kurt >> >> >> >> >> >> On Fri, Sep 20, 2013 at 10:37 AM, Michael B. Smith >> >> >> <[email protected]> wrote: >> >> >> > http://en.wikipedia.org/wiki/5-4-3_rule >> >> >> > >> >> >> > >> >> >> >> >> >> > -----Original Message----- >> >> >> > From: [email protected] >> >> >> > [mailto:[email protected]] On Behalf Of Kurt Buff >> >> >> >> >> >> > Sent: Friday, September 20, 2013 12:59 PM >> >> >> > To: [email protected] >> >> >> > Subject: [NTSysADM] Semi-OT: Network problem >> >> >> > >> >> >> > All, >> >> >> > >> >> >> > In the past couple of weeks, $work has had a problem with network >> >> >> > interruptions - frequent gaps in network connectivity were all >> >> >> > contact is >> >> >> > lost with servers for brief periods of time (1-2 minutes, >> usually). >> >> >> > >> >> >> > I could see the gaps in the graphs on my (very new and incomplete >> - >> >> >> > long >> >> >> > story, don't ask) cacti installation. Unfortunately, I've been >> unable >> >> >> > to get >> >> >> > cacti to graph CPU utilization for the switches, because they're >> >> >> > Procurves, >> >> >> > and I couldn't find a working XML file or configuration for that. >> >> >> > >> >> >> > It's always happened while I've been unavailable, until today. >> >> >> > >> >> >> > Just now, I was able to show conclusively that our core layer3 >> switch >> >> >> > (Procurve 3400cl-48G), which was hit hardest, spikes its CPU to >> 99% >> >> >> > during >> >> >> > these episodes. Volume of traffic is normal - ho huge spikes in >> that, >> >> >> > just >> >> >> > normal variation, AFAICT, from the cacti graphs. I haven't had >> time >> >> >> > to see >> >> >> > if other switches also spike their CPU, but given the gaps in the >> >> >> > graphs, I >> >> >> > suspect that's the case. >> >> >> > >> >> >> > I suspect someone is doing something stupid to create layer2 >> loop, as >> >> >> > we >> >> >> > have lots of little 5 and 8 port switches on desktops and in our >> >> >> > engineering >> >> >> > lab - and in spite of the fact that I've set our core switch as >> the >> >> >> > root of >> >> >> > the spanning tree. >> >> >> > >> >> >> > I'm setting up a box to do a tcpdump in a ring buffer with >> smallish >> >> >> > files so that I can do analysis on them more easily. >> >> >> > >> >> >> > I'm not a packet analysis guy, though I've done some looking on >> >> >> > occasion. >> >> >> > >> >> >> > Anyone have thoughts on what to look for when I start my analysis? >> >> >> > >> >> >> > Kurt >> >> >> > >> >> >> > >> >> >> >> >> >> >> >> > >> >> > >> >> >> >> >> > >> >> >> >
