CCNP SWITCH Lab Experiences

switchlab0001

As I write this, I will be sitting for the 642-813 CCNP SWITCH exam at this time next week. Leading up to this day, I have been (and will continue to through the next week) practicing with the switches I bought last year.

Previously, I posted about purchasing the switches to study from, as well as posting my planned topology. What’s funny is that looking back, even though it was just a few months ago, I can see mistakes in both the topology as well as my purchase strategy. This, of course, was due to me not knowing the material as well as I do now….

For starters, in a Layer 2 network design, you’re supposed to build redundant triangles, not squares. I know I knew that because of my CCDA studies, and I’m really not sure why I put that into the diagram.*

The second thing I’ve realized is that I overbought on switches. Or, I underbought, depending on how you want to look at it. Looking at it as if I underbought, I should have added either another multilayer switch to the topology I posted previously (or a router with at least three interfaces). This way I’d have two full separate switch blocks (which was my original intention). However, it became clear to me as I began seriously studying for SWITCH that I in fact had overbought by one 3550 and two 2950s. I’d sell them, except that at this point in time it’s not really worth it to do so. For example, I just saw better-version 2950s selling for $15 with free shipping. I have no idea how that even works because it seems like it would cost $15 just to ship them out anyway.

So, here’s what I’m using for my new and final topology, consisting of two 2950s for access, two 3550s for distribution, and another 3550 to simulate a core and/or a WAN, depending on the particular lab.

switchlabbase

One of the first things I wanted to look at was the default spanning tree topology. By pure accident, the switch at the top of the diagram was the root by default (before I even knew what it’s MAC address was). So the default spanning tree topology looks like this:

switchlab-default-stp

The next thing I did was convert all the inter-switch links into port channels.

switchlab-default-portchannel

With all default settings, I noticed that all the links automatically trunk, and the trunks between the 2950s and 3550s are 802.1Q, and the links between the 3550s are ISL. Also interesting to note is that the only port-channel load-balancing methods available on the 2950s and 3550s is either source or destination MAC address, but not both.

I didn’t really lab with VTP because it really seemed like mostly a review from the CCNA and I felt like it was pretty much self-explanatory. Likewise, I have down most of the STP basics including the idea of VLAN load-balancing by making different distribution-layer switches the STP root for different VLANs. I also felt that inter-VLAN routing was very simple.

802.1s MST was not covered at all on the CCNA. I really like the concept of MST and it makes perfect sense to me. As part of the practice (and for future labs with HSRP) I converted the port-channel links between the “core” and distribution switches to routed links to eliminate the “core” switch from the spanning-tree topology.

I found out that in order to convert the port-channel interface to a routed port, you must first convert both switch ports (with the no switchport command), and then perform that command on the port-channel interface. When attempting to perform the command on the port-channel interface first, you receive an error message stating that the port is not convertible.

Additionally, I discovered that when you convert a port-channel to a routed port, you have to redefine the protocol and grouping at the traditional interface level. So while the port-channel interface itself remained, I had to reconfigure the physical interfaces with the Etherchannel protocol and group/mode. I don’t recall reading this information in any of the books or lab manuals; it seems this is one of those things that you’d only discover on the job or in the lab. Its things like this that make running a lab very important for learning and well-worth the investment, in my opinion.

Another problem I ran into that isn’t mentioned anywhere in any of the study material is that the 2950s run pre-standard MST. This leads to a problem of links being blocked incorrectly due to a misinterpretation of BPDUs being passed between the 2950s and 3550s. With some research, I found the switches must be running IOS 12.2(25)SED or newer. My 3550s are running 12.2(44)SE6, but my 2950s only support 12.1(22)EA14. The fix for the problem is to issue the spanning-tree mst pre-standard command on all of the ports connecting to the 2950s. Before getting further into the configuration, I also noticed all of the links have a cost of 100000 (normally it’s 200000 but every link in the topology is a 2x port-channel).

I configured all switches VLANs 10, 20, 30 and 40 and with the same MST region name and revision number. When I ran show spanning-tree on all of the switches, I saw that they were all operating correctly with P2p links (and P2p-Pre-Std where appropriate), except for AS2. I also saw that AS2 believed it was the root for the two instances I created, instead of DS3. After issuing show spanning-tree mst configuration on all four switches, I discovered that I entered the list of VLANs for the instances differently on AS2. On AS2, I specified the VLANs as 10-20 for instance 1, and 30-40 for instance 2. The other switches are configured for 10,20 and 30,40. As it turns out, this does indeed make a difference. After correcting the misconfiguration, AS2 correctly joined the MST STP topology and correctly identified DS3 as the root, including Po2 as the Root port instead of Po1.

And then after that, of course, the whole reason for using MST is a command similar to spanning-tree mst 1 root primary placed on DS1 to create an alternate STP topology for the specified VLANs to load-balance the traffic like (R)PVST, but with only the number of STP instances as there is individual topologies (two in this case).

switchlab-mst

Configuring HSRP is pretty straightforward. I was able to see certain aspects of the configuration demonstrated. For example, I thought the preempt setting meant that, all other things being equal, when the active router goes down and the standby takes over, but then that router comes back up it should regain active status. However, I learned that if preempt is set on both routers, but everything else is equal, the original router does not become active but instead remains in standby until the other router goes down. This is where the priority setting comes into play.

Additionally, setting different priorities for different VLANs (for example, priority 150 on router 1 for vlan 1, but priority 100 for vlan 2 on router 1, then priority 100 for vlan 1 on router 2, and priority 150 for vlan 2 on router 2) is how you can load-balance traffic using HSRP.

Another interesting thing I tried was putting the standby IPs in different groups — in other words the virtual HSRP address of 10.10.10.2, but configured as group 1 on one switch and group 2 on the other. This causes a console message to be displayed about duplicate IP addresses. Later I realized that this makes perfect sense because the group number is what determines the virtual MAC address, so having the same IP in different groups breaks HSRP functionality due to the way IP networks operate (based on concepts learned in the CCNA).

switchlab-hsrp

I understand IP SLA and think it’s a great feature. I also understand AAA and RADIUS but have had trouble getting it to work properly so far. I’ve tried both running AAA on the access switch itself using a local username and password, and I’ve tried running a RADIUS server (though I’m not sure if it was configured correctly or not), but in either case, I can get the PC to ask for authentication information when connecting, but so far have been unable to actually connect after authentication. I’ll work on this at some point in the future; for now it’s just good for me to understand the concepts.

My equipment doesn’t support private VLANs. I think private VLANs are an excellent feature and seem simpler to implement than attempting to gain the same type of implementation using VACLs. However, for the exam it is important to know how to configure VACLs, and I practiced several times under I memorized the syntax. I was able to practice private VLANs using IOU.

Pretty much all of the rest of the topics on the CCNP SWITCH exam, such as the different security methods, seem to revolve around strongly knowing the concepts. The implementation of these different features doesn’t seem very complicated. I understand the theory well. Yet, if I were to ever implement things like this in a production environment, I know that I would first test the settings in a lab, have a well-documented implementation plan as well as a rollback plan in case things didn’t work, and of course I would have documentation to support my configuration.

I know that for the CCIE lab exam, you are given access to the Cisco “DocCD.” This has been an important reference for me again and again as I configure new things, or want to dig deeper into existing configurations to understand why things are the way they are. The perfect example is earlier in the post when I needed to understand why MST wasn’t working properly with my 2950s. The DocCD provided the answer for me.

Throughout this next week, I will continue to review my notes and study material. I am very much looking forward to passing this exam and then re-studying for the ROUTE exam. I am continuing to discover that the key to learning these topics is through repeated exposure and practice. By repeated exposure, I mean the same material presented in different ways through different sources. I haven’t found much value in reading the same book over and over again (I went through that with the CCDA, and it didn’t help me very much). However, by seeing the same material presented from different sources, it verifies the knowledge in my mind and makes it more permanent.

A great example of this is me studying for the CCDA and learning network topologies and recommended design practices, then seeing some of the same material in the CCNP SWITCH curricula. Reading the Cisco LAN Switching book from 1999 further solidified that information because I was reading about how things used to be done, and I knew when the information conflicted with current best practices, which even further solidified my current base of knowledge. It’s a pretty great feeling to be proven that you do know what you think you know.

Of course, I guess that’s also the purpose of the exam. 🙂

_____________________________________________________________

*I found out why I created redundant squares when what you really want is redundant triangles. In the CCNP SWITCH Lab Manual, all of the switch topologies are redundant squares. I have no idea why the author did this when Cisco specifically says to use redundant triangles, not squares, and even explains why!