I had the circumstances of lack of budget, broken freeware, and understandable need put me in the position of spinning up another unsupported freeware application in the form of a UCCX Call Center Wallboard. As usual, I tend to be a gluten for punishment and tend to try and fight these type of situations into submission. Luckily for me in this case, I had a great solution (UC Guerrilla’s take on the free wallboard), as well as a great resource at my disposal. That resource is none other than one of the best Exchange, Server, and Client engineers I know, and am rather happy to call a friend and colleague; none other than ibageek03 on Twitter.
Category: Real World
UC Guerrilla Wallboard on Server 2012 64bit
Permanent link to this article: https://www.packetpilot.com/uc-guerrilla-wallboard-on-server-2012-64bit/
You Coach Not Teach Troubleshooting
A colleague and I have been debating over a few months the topic of troubleshooting. My initial stance on the topic was that you CAN teach troubleshooting. However, as time has passed working with particular individuals I have came to a realization that you CANNOT teach troubleshooting. My belief now is that some people simply have a mind that thinks in logical sequences to rule out options and others don’t. While I’m sure this post may cause some heat towards myself the point isn’t to say anything bad about anyone. My point is that some individuals have a very effective troubleshooting skill set, while others simply have a set rubric of tests that if exhausted, results in a complete halt in process. I’ve come up with four items that impact an individuals ability to troubleshoot effectively even after the initial checklist has been exhausted.
Permanent link to this article: https://www.packetpilot.com/you-coach-not-teach-troubleshooting/
Bulk enable PIM via TCL
I’ve been working on doing some multicast labs lately and am constantly resetting my lab devices to their default configs and starting from scratch. As many of us know, to enable PIM on all of your interfaces you must go into each interface and enable it manually. There is no default command to enable PIM on all interfaces. We know PIM should be enabled 1 to 1 with interfaces involved in routing making this a boon. With that in mind, and the fact that I am rather comfortable with the concept of needing PIM on the interfaces, and likely speak and type this command in my sleep, I decided to make it easier and modify a previous TCL script I had written to enable PIM on every interface that has an IP address assigned to it. With the great “Send to Chat” feature of SecureCRT I can do this across my entire topology on one fell swoop. In a real world environment, you could use a tool like Solarwinds to push this out to your devices.
Permanent link to this article: https://www.packetpilot.com/bulk-enable-pim-via-tcl/
Daily Learning Actions
The other night while studying I tweeted out the first six words that came to mind as I thought to myself “How can I retain this better”. The concept is really quite simple and I find myself doing these steps for everything I am trying to learn and retain. While everyone learns *best* a certain way, everyone also learns more by being around the material more. I don’t feel I need to explain how to find what way of learning works best for you. Nor am I going to pretend to have a clue how people learn or retain better in any sort of scientific way. I’m simply going to explain my view on my six word study method.
The Method:
Read, watch, listen, learn, discuss, do!
It’s a simple mantra that you can think about every time you start studying a topic. In fact, you already learn all of these ways throughout the day. The concept here is to apply all six of them to every topic you are focused on studying.
Permanent link to this article: https://www.packetpilot.com/daily-learning-actions/
Apps for a Network Engineer Part II: Windows
Windows for Network Engineers
Part two in my series of apps for network engineers across the three major platforms. I previously did the post for Mac when I first refreshed my laptop and purchased my first new Mac in 8 years. Issued by work, my daily laptop is a Windows machine which is fine with me. I would prefer to use Mac but give me a machine that has the tools I need and I’m fine. So with that in mind, I am going to list my favorite Windows tools for Network Engineers.
Permanent link to this article: https://www.packetpilot.com/apps-for-a-network-engineer-part-ii-windows/
Linux to Cisco Openswan IPSec Configuration
[notice]For this example I use the following IP scheme 192.168.0.12|–O–42.42.42.42—–[INTERNET]——12.12.12.12–O–|10.42.42.42[/notice]
I was approached a few weeks back to assist in creating a VPN Tunnel between two end points. Of course in my naivety I readily assumed it was between to Cisco devices but that turned out not to be the case. The tunnel was to be between a Linux box (in this case Ubuntu on a hosted VPS provider) and an unknown endpoint. This tunnel was going to be host to host as opposed to LAN to LAN. After some quick discovery work, getting access to the Linux box, and seeing the required proposal from the other side I started diving into the unknown of Openswan. Luckily, after doing som research for the configuration and verification things started shaping up and much to my approval, a lot of what you would look for in Cisco verification was the same on the Linux box. The configuration goes as such.
Naturally the first step is to install Openswan. As per usual use your distributions software management to install this. The first thing I configured was the ipsec configuration file. On the Ubuntu box this resided in “/etc/ipsec.conf”. The configuration was as follows.
Permanent link to this article: https://www.packetpilot.com/linux-to-cisco-openswan-ipsec-configuration/
Trouble shoot with TDR
This article is another example of trouble shooting by putting multiple pieces together. While it relies upon existing knowledge of the environment in which the article is based it should prove to be a good example of a trouble shooting process that will hopefully be able to spark some creative thinking the next time you have a problem that needs to be resolved.
The scenario starts out with a user ticket stating that the phone isn’t working. After some fact gathering the below details and possible solutions were outlined.
Continue reading
Permanent link to this article: https://www.packetpilot.com/trouble-shoot-with-tdr/
It’s not defeat unless you quit.
Too often when talking to individuals studying for certifications tests, or just entering their field, I find them to quick to throw their hands up and say “I don’t know, it’s to far beyond me” and that is where their interest stops. They keyword I am saying their is stops. While yes, I am going to correlate much of this post to my career in information technology, this concept proofs true in all aspects of life.
So what am I getting at? Basically, I’m saying you don’t have to admit defeat. One of the best things in this industry, and your day to day life in general, is to learn what you don’t know. Contrary to my above statement, saying “I don’t know” isn’t giving up. The first thing is to admit when you don’t know, but don’t stop there, because pretending you do is a good way to get caught with your pants around your ankles. You have options as to what you do after you realize that you don’t know. The first is to follow up with “but I can find out”.
You could be saying that you’ll find out to an individual that asked you the question, or you could be saying it to yourself. The trick here is to follow through. Do some research on the internet, look up a video, find an example of the desired end result. Doing this means you haven’t thrown your hands in the air and given up, and therefor, you haven’t been defeated.
Next, you can take the opportunity to show your desire to move forward. Lets say you are asked to do a task you don’t know how to do. Follow the above concept, but say “I’m not sure how, can you show me”. This again doesn’t correlate to defeat. It is an acknowledgement of not knowing something, but having the determination to learn about it and progress.
The long and short of it is this, not knowing how to do something, having it be outside of your current skill set, or having it currently reside above your understanding is NOT a representation of your capability to do or perform the request. Only if you give up on proving you are capable have you admitted defeat.
Permanent link to this article: https://www.packetpilot.com/its-not-defeat-unless-you-quit/
Apps for a Network Engineer Part 1: MAC
MAC for Network Engineers
I am not going to play bias in anyway towards any particular apps. I’m surely not going to get into the debate between Windows or Apple as a primary computer. In fact, I’ve spent the last 4 years using Windows exclusively for work due to work issued laptops and the lack of support for Mac in the companies I have worked with. However, I recently purchased a new Mac to get back to what I personally like best, with that, I had to rebuild my app repetoir for doing my job on a Macbook. This took some digging and searching to find apps similar to what I used on Windows. I’m still searching for all the app alternatives but I figured I could make this into a working document of my favorite apps in terms of network engineering.
Permanent link to this article: https://www.packetpilot.com/apps-for-a-network-engineer-part-1-mac/
SRT: Offline type 7 decrypt
I was recently working on deploying a new device into our network infrastructure. I was working off a configuration template that had a standard arguments for AAA leveraging TACACS+. I was offsite and had asked a fellow colleague to enter the new device into our ACS deployment to allow authentication and command authorization. The long and short of it is, it was copied off of a different group of devices than what my configuration template was based of. The issue was a mismatch in TACACS server keys. The problem was I was currently offline as I was connecting to the device what would let me out to the network. So what is the stupid router trick? The stupid router trick consists of using the key chains to decrypt a type 7 TACACS (or other key) that is hidden via service password-encryption in your configuration template. The trick is pretty simple. Create a temporary key chain that won’t be applied anywhere, enter the key(s) into the key chain in their type 7 format, and then do a simple show key chains. Really! That’s all there is to it. See the output below.
R1(config)#key chain tempkeys R1(config-keychain)#key 1 R1(config-keychain-key)#key-string 7 06150A225E4B1D12000E R1(config-keychain-key)#exit R1(config-keychain)#key 2 R1(config-keychain-key)#key-st R1(config-keychain-key)#key-string 7 095F4B0A0B0003190E15 R1(config-keychain-key)#end R1# R1#show key chain Key-chain tempkeys: key 1 -- text "secretkey" accept lifetime (always valid) - (always valid) [valid now] send lifetime (always valid) - (always valid) [valid now] key 2 -- text "secretkey" accept lifetime (always valid) - (always valid) [valid now] send lifetime (always valid) - (always valid) [valid now]
Permanent link to this article: https://www.packetpilot.com/srt-offline-type-7-decrypt/