Category: Personal


CCNP certified!

Yes, I passed TSHOOT two days ago! I just waited to post here until I received the confirmation mail.

And now I’d like to say a lot, but there’s the NDA of course. I will say the following to those attempting CCNP: if you’ve mastered SWITCH and ROUTE with practice labs like I did, TSHOOT is a walk in the park. Just make sure you know a lot of ‘show’ commands and try to troubleshoot everything as logical as possible.

I’m very happy now, I can end 2011 with a goal completed. Up next: who knows? I’m still considering CCIE, but given what amount of knowledge I’ll need to learn, I’m not going to have a lot of time for it next year. But I’ll keep on learning something, that’s for sure. Not standing still here.

Thanks to all who supported me!

Advertisements

TSHOOT booked!

I decided to go for it and book my TSHOOT exam for next week, Tuesday december 20.

Do I feel ready? I have no idea. This exam is going to be more practical compared to ROUTE and SWITCH, so it’s going to be different. Luckily, thanks to my new job I feel confident about layer 2 troubleshooting, since that is what I’ve been doing mostly in the past weeks. A good thing really, because originally, layer 3 stuff like routing protocols was easier for me than layer 2.
In the past week I’ve set up a SPAN port, did troubleshooting on port channels, had to calculate PoE budgets on access-layer switches, checked VLAN usage and spreading, and so on. The SPAN port was one of the bigger challenges, as I had to do it on a Nexus, which is a whole different beast at times compared to a Catalyst switch. Perhaps more on that in an upcoming blog post.

Reviewing IPv4 routing hasn’t posed any problems so far. Even reviewing NAT again went easy. IPv6 had a surprise for me (note: redistributing something into RIPng requires a metric to be set), but no big problems either.

I’m putting more emphasis on ‘debug’ commands now. I’ve hardly used them so far, but I will need them on the exam. I was able to find out a typo in my EIGRP authentication keys with it in my lab practice. Together with the ‘show’ commands they’re probably my key to passing it.

So no new blog post until I’ve done the exam. I hope it’ll be a very happy one.

It’s friday again, facing the weekend. The good news is: this is my last day at my current job, starting Monday I’m officially a data center network engineer (same employer). Happy that my studies have paid off! On the other hand, I bragged about my studies, so I now better finish off that TSHOOT exam and prove my worth.

I haven’t blogged a lot lately, but I did make a contribution to the networking-forum.com with a blog post. Special thanks to Steve (the owner) for making this possible.

Finally I’ve had some time to work in my lab again, but I couldn’t test anything I wanted to test. So far I’m unable to bridge an interface (loopback of physical) on Ubuntu with GNS3. I need more knowledge to properly set up my IP Phones for testing, a RADIUS server would be nice, and I’m currently negotiating a new device for my lab but that’s taking longer than expected (spoilers…). So all in all, I’m spending more time configuring operating systems than doing actual labs. Part of the experience I suppose.

I did learn a few things these weeks that may come in handy:

  • When setting up larger OSPF networks, also configure a router-id. Chance that a duplicate id is formed using a physical interface ip is small, but the ‘show ip ospf database’ command makes no sense if you can’t recognise which router sent which LSA.
  • Windows 7 will show when 802.1x authentication fails. Very useful. Ubuntu gives a lot more options for 802.1x, but doesn’t give that much output.
  • Without a config to work with, an IP Phone will not allow communication between the daisy-chained computer and the switchport. I’m going to need a tftp config server, and learn some voice.
  • I’m going to have to learn SSLVPN. I got to test one briefly and it’s above my level of understanding. Luckily I’ve got a CCNP Security Secure 642-637 eBook, purchased through a Deal of the Day by CiscoPress.

And finally, looking at my last blog posts, I like making lists. Seems the best way for my mind to absorb knowledge, and I assume many people will agree on that.

By lack of time and access to my lab (it’s a busy week), I’ve done no interesting discoveries and configurations lately. Instead, I’ve been focussing on the theoretical part of TSHOOT.

I may have limited experience as an actual network engineer, but I’ve done plenty of troubleshooting on past jobs, and in my daily life. If there’s one thing I learned, it’s that there are some basic skills never mentioned in any book that can get you a long way. Some may call it talent, but I’m convinced these are mostly learned skills. In my conversations with other certified people so far, I’ve noticed the people who were best at their job were those that used these skills, sometimes even unaware of it themselves. In the spirit of my upcoming TSHOOT exam, here they are:

Gather information. One of my beginner’s mistakes was to start working towards a solution without properly checking all information. An application isn’t working – wait, can you even ping? No ping – wait, is there ARP information? One can do a lot of troubleshooting before noting the cable is unplugged, for example.

Ask questions. A stressed end-user wanting a solution for his application rarely gives all the needed information right away. Ask what you need and want to know (he’s stressed anyway, just nudge him some more). In return, don’t get stressed when they don’t know anything – Questions are mandatory, answers optional. At least you tried.

No assumptions. If you’re assuming stuff without knowing for sure, reread the above two statements.

Try it. The theoretical discussion can be fun sometimes to see who is right, but in the end, the only way to know for sure is to try out a method.

Consult documentation. Don’t know how to do something? Check it in your books, on Google, or the official documentation. Since nearly all commands are listed there, one can often find some forgotten issue.

Best-practices are often best-practices for a reason. Everyone wants to be the first to find a better method to do something, but a best-practice that’s been around for years usually indicates many engineers have tried and failed to find a better method for many years. When in doubt, stick to the trusted solutions.

Things fail. That’s reality for you. End-users often exclaimed to me: ‘But it worked yesterday!’ Well, today it doesn’t. That’s the very definition of a problem. Just something to keep in mind as a troubleshooter: stuff will go wrong, and sometimes there’s no clear cause at first (or even after it’s fixed). Just accept that and work towards a solution.

Accept advice. Someone may have encountered a certain problem before, or know more than you do. Either way, not accepting advice, usually mixed with ignoring best-practices, and making assumptions, is a great cocktail for both failure and no trust from your peers.

For most of you, reading this will be nothing more of a confirmation of known facts, but even then, it’s good to keep them in mind. If some of these things sound new to you, spend time to get familiar with them. They’re worth the (saved) trouble.

Small setback on studies.

I haven’t posted anything in a while. Three reasons for that: first, my personal life requires some attention from time to time too, of course. Second is that I’m currently finding it hard to start studying again. It’s the same feeling that I had after the ROUTE exam: just finished one pile of work, and facing the next one. I’ll get out of it again, I’m sure.

And third: my main computer broke down a few days ago. I ended up buying a new case and a new PSU for it. The case wasn’t the problem, though I originally thought so because the computer wouldn’t turn on and I could hardly press the power button on the case. The old case was a cheap non-brand case. The new case is an Antec VSK2000, which is much more sound proof and feels a bit sturdier too.

Everything is repaired now, and I’m back in business. Hopefully next week I’ll bring some more interesting news. Good luck to everyone studying out there, and keep your head up: you’ll get there.

5,000 views!

Today my blog reached the 5,000 views mark! Since I started this blog only three months ago, I don’t consider that a bad start. Most of my views come from the Cisco Networking Academy Facebook page on which I’m active from time to time, so thanks all for the interest in the subjects I’ve written about so far!

Besides that I see some daily Google searches coming in, which gives me some confidence that I’m not writing total rubbish. Not surprisingly, most searches handle about subjects that are badly documented, notably Spanning Tree under Windows, PoE, broadcast pings and Vyatta-related searches.

I’m really happy to see my blog having subscribers, being shared on Twitter (and I don’t have a Twitter account myself), Google Reader, and having a small but loyal group of readers. Thanks to all of you!

Now, back to my studies. I haven’t done anything all week and I still need to pass the CCNP TSHOOT exam. Stay tuned!

Last friday, I had a WebEx video interview with Hilal from Cisco. Hilal is a moderator on the official Cisco Networking Academy Page on Facebook. Since Facebook has some issues with video in general, the interview was uploaded to Youtube (see the full interview here).

In case you’re wondering why I’m holding on to the telephone horn all the time: apparently if you put a 7912 IP Phone on speaker, no one will hear you anymore. As for the rest, I think it went well for my first video interview and perhaps I’ll be doing more similar things in the future, who knows. Never say never.

Greetings!

CCNP SWITCH passed!

I did it! I passed the 642-813 Implementing Cisco IP Switched Networks exam today. Together with the ROUTE exam in August I now have two out of three exams done for CCNP.

Since this is the fourth Cisco exam I’ve done, I’m starting to see patterns. I’m pretty sure they hired a psychologist when creating these exams, as some of the questions seem to be put in such a way they completely throw you off guard. My first question was a CCNA-level question which didn’t really relate to the rest of the exam and CCNP-level switching in any way. I also had that feeling with the ROUTE exam: the first two questions did relate to the required skills, but in a completely different way, making me doubt myself.

Fortunately it wasn’t that bad this time as I was confident when starting the exam. I’ve practiced all commands to the point where I could configure the switches in my home lab with every possible command in half an hour without consulting any documentation. Just like ROUTE, I’m sure this saved me. The real equipment in my home lab, reading documentation on the Cisco website, reading RFCs,… It’s a lot of work, but I would recommend it to anyone pursuing certificates to do so.

So, one more exam for CCNP: the TSHOOT. When I started CCNP studies, I had hoped to complete it by the end of the year. So that gives me two more months for one exam. It would be nice if I could do that, and it looks realistic too, but I’m not really using it as a goal anymore. Next week I’ll start studying again and we’ll see how it goes.

Things I picked up this week.

It’s starting to become a tradition for me to list up the things I’ve learned in the past week. I’ve been able to dedicate some time to my lab the past days, and again I’m happy I’ve made the purchase. You just encounter too much details with the real material that aren’t covered by any book. Also, I tend to learn faster by doing, and actually seeing the output of all the ‘show’ commands helps, as well as figuring out what I did wrong this time. If you’re reading this, trying to get certified and don’t have a lab yet: get one. Now. I can proudly say I haven’t failed a single exam so far, and I intend to keep it that way.

Back on topic: here’s my list of this week’s surprising discoveries.

My 2970 has no LLDP support. I didn’t expect that from a gigabit switch. I’m going to check out, when I have the time, whether this depends on the IOS or not.

Private VLANs can’t be combined with a voice VLAN. Not completely surprising given PVLANs were designed with server- and ISP-infrastructure in mind, but it’s a missed chance I’d say. Maybe this will change in the future.

A badly formatted DHCP packet will make a DHCP client reject IP addresses. I’m referring to my experiments with DHCP options: if one of the options contains the wrong information, the DHCP client will reject all information, even if a valid IP, default-router and DNS are offered. A Windows client will then default to a 169.254.0.0/16 IP, which gives the impression no DHCP negotiation took place at all. Luckily, Wireshark clearly identifies this problem.

Again DHCP: if a Cisco router or switch (SVI) uses DHCP, the received default-router is added to the routing table as a next hop of a default route, with AD 254. This is quite useful for rapid deployment, and the high AD makes sure it doesn’t interfere with the routing protocols.

IP Phones can ping but don’t respond that well to it: on average they take 60ms to respond, other hops not included. My guess is the echo reply must be done in software, and the IP Phone has a low speed processor. Probably voice encodings are done with an ASIC, or just don’t need that much processing power. But I’m no voice expert.

Also, when pinging, the advertised TTL is that of the return-path. This means it depends on the target device TTL which value you’ll see, and in case of a different return-path, the TTL is not accurate.

I’ve always wondered why Cisco switches don’t have a CST (Common Spanning-Tree) option, just MST, PVST and RPVST. Now I know: MST in it’s basic setting (one instance for all VLANs) acts just like CST. So just configure MST in a multi-vendor environment and it should work. If I ever have the chance, I’ll test it to be sure.

And finally: for some reason port costs in MST are not the same as in (R)PVST. This means you have to be careful when migrating from one STP implementation to the other, especially when port costs are configured.

Weekly progress.

A busy week it was once again. Special thanks to my friend Steve from Alfa+ who helped me finding half my current home lab, and delivered a rack on Tuesday to put all my networking stuff in. Now it’s less cluttery, it takes less space, and it’s more secure behind a locked door.

I’ve upgraded the remaining routers, bringing all my 2611 routers to IOS 12.3(22). No IPv6 support, but it’s the most recent IOS the flash can hold (2611’s have only 8MB flash), and they now support a range of commands, from QoS to VRRP. I’ve also cabled up the rack, and replaced faulty cables: one ethernet cable didn’t gave any signal anymore, and one power cable caused unpredictable reboots, so that’s solved too now. After that, some labs. I learned the following things this week:

If you make mistakes when configuring HRSP, it’s not always immediately visible in the network, but it often causes MAC address flaps on the switches, which gives an early warning that something is wrong. Also, when finetuning the timers, setting them too low will make the entire HRSP setup unstable because minor hiccups trigger many events.

HRSP with authentication is at times quite pointless. I’ve noticed instances of HRSP with the wrong authentication that kept being active on the network. It’s better to implement logging and alerting to warn when changes are detected, and the above MAC address flaps are noticed, because that’s a typical symptom if everything else seems fine. It’s not really something that can be solved easily: if router A uses HRSP with password Test01, and router B uses HRSP with password Test02, which one is the legitimate router, and which one isn’t? It seems both routers assume the other is wrong and start being an active HRSP router, ignoring the other.

ROMMON mode allows for the direct manipulation of boot settings. It’s never fully explained in any Cisco source for any certification, but it’s really worth looking into. If, no, when something goes wrong and you know your way around ROMMON, you can recover everything in no time. You can also boot an IOS from TFTP to test it, before downloading it to the local flash.

The ‘ip address dhcp’ command will make the router somewhat function like an end device and, depending on the IOS version in use, the received IP will be stored in the running-config, along with a default-gateway. IP options so far do not seem to be copied in running-config. Also, if your DHCP server is a Cisco device, it seems to recognize the difference between a Cisco router and a computer, because the lease time is set to infinite, despite that this is not defined in the DHCP pool. I’m not sure, but it seems to suggest these devices work together (perhaps with CDP?) to allow for speedy network deployment without the disadvantages of dynamic IP addresses. I would research it some more, but it’s really not a priority right now with the CCNP SWITCH exam in mind.

A 3560 switch, to my surprise, supports Auto-MDIX, allowing me to connect switches together using straight cables. It seems you can check it with a hidden command (not visible when using ‘?’): ‘show controllers ethernet FastEthernet0/1 phy’. Nevertheless, I’ll keep using my cross cables for the port aggregation labs, but I now can use my longest (straight) UTP from switch to switch, which comes in handy.

Hopefully next week I’ll make some more progress. Greetings!