This post is primarily for archived documentation for myself in the event of possible future need. However, I was having a hard time finding any configuration examples for this task. The steps below are those I used to connect a 70inch Infocus Mondopad to our CUCM environment to be able to make video calls including sharing the Mondopads screen over the called Cisco phone.
Infocus Mondopad Registered with CUCM – SIP
Reading Time: 2 minutes
Permanent link to this article: https://www.packetpilot.com/infocus-mondopad-registered-with-cucm-sip/
Synapps Paging Delays – An HTTP/TCP Wireshark diagnosis
Reading Time: 5 minutes
The Scenario goes like this: A Synapps – SA Announce paging and messaging server integrated with Cisco’s CUCM hosting around 30 phone to phone paging groups. The paging had been working fine for months and out of no where one of thirty particular groups was putting in multiple trouble tickets over multiple days that the paging isn’t working.
So begins the troubleshooting and diagnosis. My first action was to monitor the paging server as it has a real time display of who is calling a paging group and which group they are calling at in given time. When I was monitoring this I could see multiple people calling multiple groups including the one in question. So this brings up one of those “what gives” questions. Are they just doing something wrong up in the area. Time to take a trip and raise that pedometer count.
I arrive in the area and try and locate and area where I can visually see and hear multiple phones. Easier said than done but in this case I was the only one available to work on the issue and knowing that the paging server will activate the speakerphone and mute lights when a group the phone is a member of is called this was my best bet and understanding what was going on. After making my first test page I can see that lights on the phones I can see are immediately lighting up, however I can’t hear audio. As I stand there dumbfounded with the phone still off hook all of a sudden the audio starts picking up the background noise. However, paging shouldn’t have a 6 second delay before you can start talking. Six seconds is a long time to wait after hitting page to start talking. So whats going on? It’s only one group experiencing this. What is different about their group? Time for a deep dive in the diagnostics world. Enter Wireshark.
Permanent link to this article: https://www.packetpilot.com/it-was-broke-but-the-sharks-got-to-it/
Trouble shoot with TDR
Reading Time: 5 minutes
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/
IP SLA for Single Default Route Change
Reading Time: 5 minutes
The scenario goes like this. You are working at your office (R1) and need to change the IP address and default route on the remote device (R2). The issue a factor of two things. The first is the fact that R2 is connected to your network with only one link. The other issue is R2 cannot use any dynamic routing protocols so you are stuck with a default route that is pointing at the next hop. If you are to change either of these facts you lose connectivity to R2. While there are other solutions to making this change, I am going to take the concept of floating static routes and an IP SLA to change both the IP address and the default route.
Permanent link to this article: https://www.packetpilot.com/ip-sla-for-single-default-route-change/
It’s not defeat unless you quit.
Reading Time: 2 minutes
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
Reading Time: 5 minutes
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/
Initial Router Setup For Remote Access
Reading Time: 3 minutes
[notice]PacketPilot / P2Labs does not guarantee any certification results in using the content of this website. Please keep in mind these are free tools to aid in your learning and certification goals. All efforts are made to ensure the accuracy and content in these labs. Hard work, dedication, and official Cisco training materials are recommended for your training.[/notice]
The following lab can be completed using any Cisco Emulator supporting the appropriate feature(s).
The purpose of this lab is to reinforce basic router configuration including naming the router, connecting two routers via an ethernet connection, and establishing logon procedures for remote access including secure remote access. Remote access if a key design feature of any network. It provides efficiency of management by preventing unnecessary trips to distant devices for simple tasks. Secure access is provided to prevent unauthorized access and data gathering from packet captures on plain text traffic.
Permanent link to this article: https://www.packetpilot.com/initial-router-setup-for-remote-access/
SRT: Offline type 7 decrypt
Reading Time: < 1 minutes
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/
Automated IP Communicator Launch against Multiple Clusters
Reading Time: 3 minutes
If you manage multiple CUCM clusters you are likely to have Cisco’s IP Communicator installed on your computer. Cisco IP Communicator is a software based phone installed on your computer that connects up to CUCM and lets you utilize your PC as if it’s a Cisco desk phone. This is a pivotal tool to quickly move a phone between different call managers. I recently fell into this demographic while working on a migration/collapse of multiple CUCM clusters. A lot of time was spent in the GUI of IP Communicator changing TFTP Server address (let alone trying to remember them all). I took a couple of hours and figured out what would be needed to automate this task via a batch script with a simple menu based script. The details are found below.
To start, I found that the TFTP servers were stored in the registry. However, these TFTP servers were not in standard IP address form. They were actually stored in Hex, but the octets were rolled over while keeping the bits in the standard left to right order. The process to create the correct value’s for the registry is as follows.
Permanent link to this article: https://www.packetpilot.com/automated-ip-communicator-launch-against-multiple-clusters/
Tracked Static Default Route
Reading Time: 6 minutes
As common place in today’s networks redundancy is key. Applications are the key components to business obtaining revenue. More and more applications are becoming SaaS and ecommerce is here to stay. With that being said, many companies are moving to redundant connections to the internet. These connections could be through two different ISPs, or both connections to the same ISP. Often times these connections will be of different speeds to save on costs. The key to these connections is to maintain internet connectivity.
Permanent link to this article: https://www.packetpilot.com/tracked-static-default-route/