Being in Networking and dealing with Cisco gears on a daily basis requires the use of a terminal application in order to configure and manage your devices. I’ve used both SecureCRT and Putty but I find myself using Putty a whole lot more. It’s a small application that doesn’t even require an install before you can use it. You simply download and run it. It’s also freeware which is an added bonus.
Due to the number of problems I’ve had with Windows and my laptop, I found myself having to reload quite a number of times. Each time resulting in me losing all my device profiles I had configured and saved in Putty. Because of how the program is written there is no configuration file(that I know of) that I can save and then import whenever I do a new install. This totally sucked, as I was able to backup my configs using SecureCRT. Doing some research led me to this article that showed exactly how to export/import your configurations in Putty. To avoid me having to google around again for such an article just in case I need it in the future, I’ve decided to simply make a copy of the steps required here for my convenience. All credit goes to the author of the article mentioned above for writing such a detailed post on the how to accomplish this.
- Open Regedit.
- Look for “SimonTatham” by using the find option (ctrl f).
- Export the reg file by clicking Export from the File Menu.
- Choose the path to store the registry key and hit enter.
- To import the settings in a new Desktop simply copy the registry key to that system and double click to apply the registry setting. At this stage you simply download Putty on the new system and run it, you will notice that all your devices are already populated in the list.
This will definitely benefit me in the future and hopefully those of you who aren’t yet aware of how to backup your configs.
Over the past couple of weeks I’ve been experiencing a strange problem with one of our client’s network. They payed for a 5Mpbs connection but had the ISP opened up the pipe to 100Mbps temporarily to their DR site to allow for the initial replication of servers to move a lot faster. The problem was that we weren’t getting anything close to 100Mbps whenever we did speedtests. Results averaged in the 40Mbps range and sometimes it would even get as low as 18Mbps.
Before I go any further, let me give you a brief overview of the current design. The client has their own /24 block and ASN. The same ISP that is providing their primary internet at HQ is also providing internet at the DR site along with the lease line that connects them. eBGP relationships have been established to the ISP at each site along with an iBGP peering between the HQ and the DR. They’re also using EIGRP as their IGP.
After the above configurations were completed I performed some initial tests. We were receiving a partial table at the DR site while only getting a default route at HQ. To prevent the upstream ISP sending the full table unexpectedly I configured a prefix list at both sites to only allow a default route in. Further tests were performed to ensure IGP was routing properly and that both sites were learning routes from each other. The issue arose when we were ready to test replication of the servers at HQ to the DR site. The ISP informed us that they had opened up the pipe to 100Mbps and that we could begin replication. However, conducting a number of bandwidth tests on speedtest didn’t concur with their confirmation. Speeds were fluctuating greatly but didn’t get anywhere close to 100Mbps. This was where the troubleshooting process began and what highlighted my BGP design #FAIL.
Now there could be any number of reasons why I wasn’t getting the desired results. So how do you go about troubleshooting such an issue? A carefully planned process and my good old buddy google. That’s how! The next step I did after testing on my laptop was to test on some other desktops and servers in the network. This would allow me to eliminate my POS laptop that freezes a zillion times a day out of the equation. The tests performed on the servers yielded the same results. Ok, so now we’re moving on to the next set of tests to perform. Before performing anymore tests internally I decided it would be more productive to test from the ISP’s fibre switch and walk my way into the network. It really didn’t make any sense performing a bunch of tests on the internal network when the problem might be with the ISP’s switch, the border router or even the PIX(shoot me now) that are all inline before hitting the internal network. The link comes in from the ISP via fibre, into their switch and then connects to the border router via ethernet. The border router then connects to the PIX. To ensure I was getting the desired bandwidth from the ISP I connected my laptop the to the fibre switch, placed the IP address used to peer up and then perform tests. Results were good. I was getting 98Mbps on average. Ok, so this proves that we are indeed getting the full bandwidth. The next step was to connect back the fibre switch to the border router then connect the router to my laptop. The results of these tests weren’t promising. So now I’m baffled. Could it be the border router? It can’t possible be! It’s a brand new 2901 ISR generation2 and as you know, the new ISRs are built to handle a lot more bandwidth. Time to hit up my friend google. I found another user with the exact same model router with the exact same design using a fibre switch from their upstream ISP, who was having the exact same problem. A lot of users were saying it could be a duplex/speed issue with the ports however this wasn’t the case for me as both the speed and duplex negotiated correctly. I saw @jastorino on skype around the same time I was researching the issue so decided to pitch my problem to him see what input he had. One idea that came up was that it could be possible that the ISP was doing rate limiting via sourced traffic. This made sense as when I connected directly to the ISPs switch using their IP I got full bandwidth, but when I connected to the router using IPs from the client’s block we didn’t. They denied that they were rate limiting as I was suggesting. At this point I knew I must be on to something. Why would I get full bandwidth when traffic was sourced from the ISPs IP but didn’t when it was sourced from the client’s IP. Something’s not right. Moving on, I checked to see how the client’s block was being seen as reachable from a couple of BGP looking glass. Performing a traceroute to an IP at the HQ revealed something quite interesting. The path traffic was taking to reach HQ was through the DR site. This meant that traffic was not taking the same path to return into the HQ network as the path used by exit traffic. This lead to a loud outburst of ooooooooooooooooooooh while at my desk :). Everyone around me wanted to know what happened. So now I’ve found the problem! The internet facing link at the DR site wasn’t opened to 100Mbps while the lease line was. Return traffic was actually being limited by the DR’s internet link. How do I fix it? My first thought was to split the /24 block into two /25 then reconfigure BGP to advertise those blocks to the upstream. This would allow return traffic to take the same path a the exit traffic depending on which block it was coming from. Unfortunately because ISPs wouldn’t advertise any prefix smaller than a /24 this was no longer an option. Using AS prepending was the next fix for this scenario. Prepending the client’s AS 3 times at the DR site made the AS path appear much longer than that of the HQ and because of BGP’s path selection process, return traffic would choose the HQ site.
I know this probably isn’t the best solution but it worked just fine for me. I’m by no means an expert at BGP. However, working on this project exposed me to a lot of good factors about the protocol that I will be sure to take into consideration during future designs.
Today’s task was to deploy a couple of 7962 Phones along with some 7915 Expansion Modules. This shouldn’t be too bad. All I need to do is head over to the client with the gear and configure their CME to accept the new phones and modules. How hard could this be? This should take me probably 2 hours max! Heh! Don’t know who I was kidding. By now I should be well aware that nothing goes as planned in networking, more so in Voice :-).
So I’m over at the client and begin by unpacking the phones, connect them up to the switch and begin my CME configurations. Ephones created, phone registers just fine and hey! I was even able to successfully place a test call. Things are progressing as planned. Next up is to test the expansion modules. Connected up the 7915 modules but for some reason they wouldn’t power up. Did a quick search on google and turns out that these modules need power supplies if the phones are power via POE which was the case here. If the phones are powered via power supply, then you don’t need a separate power supply for the first module. However, for the second module you most definitely require a power supply. Good points to know. So after heading back to the office to acquire a power supply, I was able to get the modules powered up. Now they powered up just fine but didn’t display the lines they were configured for. They just sat there stuck with the amber lights on. Time to hit up my buddy google again. He pointed me to some really cool forums which informed me that the firmware on my phone needs to be at 8.4( they’re currently 8.3 at this stage). Five minutes later and I have ver 9.2 downloaded and copied to the UC560. Rebooted the phones so that they can begin the upgrade process only to be hit with more good fortune. For whatever reason these phones weren’t upgrading. The process kept failing. Eventually I think I tried so many different stuff that the phone would not complete the boot process anymore and load it’s configuration. It would just stay stuck at “Upgrading” and then reboot, going through this cycle repeatedly.
At this point I figured da hell with it! Reset this baby to factory default and start over. If you head over to Cisco’s site for instructions on how to restore this model phone to factory default, they state this. After ensuring that I had everything in place as advised, I proceeded with the reset sequence. This proved to be unsuccessful. After entering 123456789*0# the phone simply went back to the state of “Upgrading”. My frustration level at this point was of course reaching max. Ok, so time to turn on some debugs and go from there. Enabling debugs for tftp enabled me to see what files the phone was looking for. First file I noticed it was not finding was “term62.default.loads”. Rechecking my tftp-server configurations revealed that I had the alias configured incorrectly, leaving out the .loads which prevented the phone from finding the file. I corrected this and proceeded with the factory reset procedure once again only to be greeted with the same error. This time the file that couldn’t be located was “jar42sccp.8-3-3ES2.sbn”. This one really puzzled me as the tftp configurations for this file was correct! This was where the engineer in me came to life! Comparing the firmware files I noticed that the very first file the phone looks for “term62.default.loads” was a lot smaller than the other files. It was 1KB to be exact, when compare to others that were 2439KB. This lead me to believe that this file probably just contained instructions. Opening the file with notepad revealed some gibberish followed by an orderly list of files. The files in this list were the same firmware files but in a particular order. Comparing the order the files were listed in to the order I had my tftp-server statements showed that my statements were in a different order from that of the list. This got me to thinking that maybe I should reorder my statements to the same order that was in the file. This indeed proved to be the problem because as soon as I reconfigured my tftp-server statements the phone successfully restored to factory default. Ok, so I’m some what relieved at this stage. I got the phones back to a working state however, the 7915 module still doesn’t work as we’re back to the 8.3 firmware. I proceeded to use the same logic used to perform the factory restore and retried upgrading the firmware with ver 9.2. This too was successful and the module booted up and dispalyed it’s configuration correctly.
I highly doubt this is how this procedure is supposed to work, though. What happens if your tftp server isn’t the CME device and it’s actually a server? How does it know the order? Maybe this was just a bug in my case as I haven’t seen any other reports of this while researching the issue. In anycase, it was a learning experience, one that will surely help me in the future should I encounter this problem again.
So, I finally managed to complete the final two exams remaining to achieve my MCITP Enterprise Administrator.
- TS: Windows Server 2008 Applications Infrastructure, Configuring (Exam 70-643)
- Pro: Windows Server 2008, Enterprise Administrator (Exam 70-647)
No doubt, these two were definitely tougher than the previous exams taken to achieve MCTIP SA. I think this was mainly because of the new technologies that were covered.
The 70-643 exam focused more on being able to prepare your network environment for the different applications/technologies being deployed in today’s enterprise. Virtualization and Remote Desktop Services played a big part in this. Microsoft really has implemented a lot of improvements into the Remote Desktop Service role, formerly Terminal Services. One such improvement that I am very impressed with is that of the Remote Desktop Gateway. Before, the only way of allowing remote desktop access to internal terminal servers/client desktops, would have been to open port 3389 on your company’s firewall and forward that port to the particular system or you would need to install a third party software like Logmein. With Remote Desktop Gateway, we now have the option of using port 443, which is already open on many corporate firewalls, to allow remote desktop access to internal client desktops. Topics covered also included:
- Deploying Servers
- Configuring Remote Desktop Services
- Configuring a Web Services Infrastructure
- Configuring Network Application Services
Windows Server 2008 Enterprise Administrator is the professional exam required to complete the MCITP EA. This exam is focused more on the design aspects rather than exact configuration steps required for a particular scenario. This was definitely the most difficult of all the exams I took for the MCITP SA/EA. Some of the topics covered were:
- Planning network and application services
- Designing core identity and access management components
- Designing support identity and access management components
- Designing for business continuity and data availability
So now that I’ve completed this, you may be wondering what’s next. I’m going to be going after the MCTIP Enterprise Messaging Administrator 2010. I’ll go into further details in a later post describing why I chose this as my next cert and what training materials I’ll be using. For now, I just wanted to give you a short update on my studies.
The Microsoft Certified IT Professional Server Administrator is just one of the available specialties within the MCITP certification program. At first when I heard about the revamping of Microsoft’s certification program, I was confused somewhat as to how this will all be integrated into the current IT infrastructure. Before, we were accustomed to being called a MCSE/MCSA and now we were going to be called MCITP blah blah. As with most humans’ initial response to change, I really wasn’t feeling this move. However, I must say that after getting more familiar with how the new program was designed to address professional’s knowledge and skill set, I’m absolutely in love with it. There is a plethora of specialty certs to choose from with this new program. I’m not going to go into further details on those. I’m just going to focus on what I’m currently studying for and why I chose these.
So where was I? Ah! MCITP SA. I guess you can compare the MCITP SA to the MCSA of the old certification program. To attain the MCITP SA status, one would need to pass three exams.
- TS: Windows Server 2008 Active Directory, Configuring (Exam 70-640)
- TS: Windows Server 2008 Network Infrastructure, Configuring (Exam 70-642)
- Pro: Windows Server 2008, Server Administrator (Exam 70-646)
Unlike the old MCSA which required a “client and a specialty exam”, the MCITP SA doesn’t require these. Instead you have the MCTS certification program which has sub sections which further describe which particular Microsoft technology you’re proficient in, hence the name Microsoft Certified Technology Specialist. 🙂 Also, if you already are certified in MCSA (like me), then you have the option of just taking two exams.
- TS: Upgrading from Windows Server 2003 MCSA to, Windows Server 2008, Technology Specializations (Exam 70-648)
- Pro: Windows Server 2008, Server Administrator (Exam 70-646)
Passing the 70-648 upgrade exam gains you MCTS on both Active Directory and Network Infrastructure, basically killing two birds with one stone. This was the path I chose in order to upgrade my MCSA to MCITP SA. I had completed the 70-646 exam a couple months back, but never took the time to push through and finish up the 70-648. I was too busy studying for other certs and learning other technologies, mainly CCNA Voice, MCTS on MOSS 2007 and also CCIE R&S written.
As is the pattern with MS upgrade paths, there are a number of options available to you. I decided to go with the Windows 7 Configuration for my Client exam, as I’m working with Windows 7 everyday, have a really solid understanding of it and also the fact that I really, LOVE Vista! No really! I loathe Windows Vista so much that I decided to skip it and go with Windows 7. I’m sorry, did I just say loathe? I meant love. 😀 Well, you get the picture. Anyways back to what I was saying. I was able to complete the Windows 7 exam today (70-680). So currently I have 2 more exams to complete before I’m fully upgraded to MCTIP EA. As usual, I will keep you guys posted as to my progress.
Hey guys! I just wanted to update you on my study progress. I passed the CCNA Voice exam last week, which now means I have 5 exams left to get my CCVP. I’ve started to read the CVoice book for the second time and I must say, it’s been a whole lot smoother thus far. I’m really happy with my decision to have done the CCNA Voice first before going straight into the CCVP. This really gave me a good foundation on the Voice technologies. CVoice is a really tough course, packed with a LOT of theory, so having a good foundation in my opinion is essential to helping you understand the many topics that are covered.
I’m also continuing with my CCIE written preparations. I’ve completed reading the book once thus far and I’m currently going through the INE Advanced Technologies COD. I’m still deciding on whether to read more books or whether to just reread the study guide a number of times and also do in depth research on the Cisco Doccd. I’ll let you guys know through my blog what I’ve decided.
Well that’s all for now. Hoping to have a very successful week of studies and hope you guys have the same. J
Well it’s been couple months since I passed my last exam to become a Cisco Certified Network Professional. After that my director told me that I needed to get started on my CCVP studies. I must say, Cisco Voice was something I was hoping to not have to deal with at this point in my career. I really have no interest what so ever in it. But director’s orders are director’s orders. After all, he signs my cheque at the end of the month: P. So anyways I started studying for the first CCVP exam, CVoice. It’s been a pain, a drag and very depressing at times. All that coupled with not having a mentor for it, well, that was before my buddy on twitter @james_key started helping me with stuff. Since then, it’s been a lot better and even though I’m still way behind on my voice studies, I’m beginning to make progress. J So you might be reading this and wondering why on earth I called this post “Resuming my CCIE Studies”, right? Well, truth is, R&S is where my heart is at, at the moment. And even though I’m studying for my CCVP (which I MUST get this year) I can’t help but long for the chance to get back into the R&S studies. So with that, I’ve decided to begin back my CCIE reading. Right now I’m at Chapter 11 – BGP Routing Polices in the CCIE R&S Official Study Guide. I spent some of my free time at the office today reading this chapter and also began watching the INE Routing & Switching Advanced Technologies BGP section, to get a better understand of what I’ve been reading so far. It’s coming along pretty ok and I hope to retain most of what I’ve learnt thus far.
Well, that’s all for now. I hope to update this blog more often so that you guys can follow my progress in my Quest to get my CCIE #. J