I like it! :-) -- Espi
On Wed, Sep 25, 2013 at 1:37 PM, Jonathan Link <jonathan.l...@gmail.com>wrote: > 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 < > michealespin...@gmail.com> 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 <kurt.b...@gmail.com> 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 >>> <michealespin...@gmail.com> wrote: >>> > C-D-A, yep yep. >>> > >>> > -- >>> > Espi >>> > >>> > >>> > >>> > On Sun, Sep 22, 2013 at 6:56 PM, Kurt Buff <kurt.b...@gmail.com> >>> 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 >>> >> <michealespin...@gmail.com> 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 >>> >> > <mich...@smithcons.com> >>> >> > wrote: >>> >> >> >>> >> >> I still use it. >>> >> >> >>> >> >> >>> >> >> >>> >> >> Violate the rule at your peril. :P >>> >> >> >>> >> >> >>> >> >> >>> >> >> From: listsad...@lists.myitforum.com >>> >> >> [mailto:listsad...@lists.myitforum.com] On Behalf Of Jonathan Link >>> >> >> >>> >> >> >>> >> >> Sent: Friday, September 20, 2013 2:07 PM >>> >> >> >>> >> >> >>> >> >> To: ntsysadm@lists.myitforum.com >>> >> >> 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 <kurt.b...@gmail.com> >>> 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 >>> >> >> <mich...@smithcons.com> wrote: >>> >> >> > http://en.wikipedia.org/wiki/5-4-3_rule >>> >> >> > >>> >> >> > >>> >> >> >>> >> >> > -----Original Message----- >>> >> >> > From: listsad...@lists.myitforum.com >>> >> >> > [mailto:listsad...@lists.myitforum.com] On Behalf Of Kurt Buff >>> >> >> >>> >> >> > Sent: Friday, September 20, 2013 12:59 PM >>> >> >> > To: NTSysADM@lists.myitforum.com >>> >> >> > 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 >>> >> >> > >>> >> >> > >>> >> >> >>> >> >> >>> >> > >>> >> > >>> >> >>> >> >>> > >>> >>> >>> >> >
