Ok so I’m doing Volume 3 Lab 7 today and I’m about 2 hours into it. I’m doing basic stuff like configuring Layer 3 links between switches. No big deal, everything pings and checks out fine, connectivity verified. I then make my way to configuring RIP across the switches, again, cake right? Yup, you would think so until I looked at one of the switches and noticed it wasn’t getting the RIP routes (I mean come on, RIP is too easy!). Now I knew connectivity and IP addressing was good because I verified I could ping between switch links earlier and I really haven’t done much of anything else (RIP was the first routing protocol to configure). So then I start going back to basics and verifying basic connectivity. Ok, so let’s ping our directly connected neighbor across the layer 3 link. Hmm… Some work, most don’t! So then I start staring down the IP addressing and making sure I got the right links configured, you know, the obvious. Now I start getting mad because I know things pinged just fine before and I haven’t configured anything weird on the layer 3 links to stop my directly connected neighbor from talking to me.
Here’s my scratch paper, not that it makes a lot of sense…
I then do some more pings to my directly connected neighbors, now some work and others don’t. Again, I’m only dealing with my switches here because that’s where I have RIP, and I didn’t notice things were broke until RIP wasn’t working right.
I know it’s not a routing issue because we are talking about directly connected networks here so we should be safe. So out of frustration, I save the configs, and reloaded all four switches (knowing that’s not the issue but I was doing it anyways).
So they come back up and now things are working…. Wait, they stopped again! Rip routes are disappearing slowly and now I’m having ping trouble (encapsulation failed on debug!) Ok, lets see what I could have done that may be related….
- Port Spanning
- Flex link config
- Storm control
So I’m thinking I didn’t configure any of these things on the L3 ports so how could it be affecting me? I start looking at backup port configs closer (flex links) and noticed the DOC CD said it disables spanning tree on the link so make sure you don’t have a loop in your toplogy (and there is a loop in the topology so…). Right away I knew I probably had a switching loop happening but how was it affecting my directly connected device connectivity on L3 links? Well, I then went with the old “show process cpu” command. See below
Ok, right when I saw this, I knew I had a switching loop for sure that was pegging the CPU enough to cause RIP not to function right and pings to randomly work… So when I removed the “switchport backup” commands, the CPU instantly dropped on the switches. At this point, I had already wasted an hour, so I wasn’t going to try to figure out how to block the loop.
So the question is :: Did they do this on purpose? My guess is probably so, but I haven’t gone through the walk-through yet. I’m not exactly sure what to do about fixing it since spanning tree gets disabled on that link. I did have my spanning config pretty basic as well, I didn’t lock down any trunk ports that were carrying the remote span vlan.
I tell you what, if this was on purpose, what a brutal lesson to be learned! Ouch, this costed me some time, and you have to fix it or it screws everything else up in the lab. If today was the real lab, I would have ran out of time…
**Update*** Ownage confirmed. The walk-through did mention the looping problem caused by Flex links disabling spanning-tree. They did mention the solution as far as limiting even/odd vlans over certain trunks and even shutting certain ports down. Basically, the flex links pretty much screwed our spanning-tree making us manually make it loop free (not something that’s fun). It even involves shutting down certain ports (spanning-tree does this for us). Just a word of caution :: When you see Flex Links, your eyes should widen (I know mine will!). This one problem will break your whole lab, trust me. I’m glad I did this lab.