Reading Time: 5 minutes
The Bootstrap Process
In the Part 1 of this series we covered the first step to converting and ISR from IOS-XE onto the Cisco SD-WAN platform. We will continue from there with my story of frustrations and the discovered caveats and need to knows. Starting first with bootstrapping the ISR.
Permanent link to this article: https://www.packetpilot.com/cisco-sd-wan-isr-4k-getting-started-part-2-bootstrap-process/
Reading Time: 3 minutes
Upgrading from IOS-XE to SD-WAN Code
Recently I was building out a lab to iron out a migration onto the Cisco SD-WAN (Viptela) solution. As part of that process existing ISR 4k routers were going to be used at the edge devices. This process, while fairly straight forward, came with a few “gotchas” and “snags” that I had to work through. In this post I will cover the upgrade of the ISR onto SD-WAN code. In the next post I will cover the bootstrap process as well as a couple of caveats related to vManage and the ISR4k routers.
Permanent link to this article: https://www.packetpilot.com/cisco-sd-wan-isr-4k-getting-started-part-1-upgrading-code/
Reading Time: 8 minutes
I’ve been lucky enough to attend Cisco Live twice with both instances being on the full conference pass. This year, due to out of pocket expenses and the overall higher cost of San Diego I am attending on the lower cost Explorer Pass. In years past I purely interacted with Cisco Live remotely. This guide is intended to combine the best of both to assist in making the most of the Explorer pass. With that in mind, lets get some housekeeping out of the way.
Permanent link to this article: https://www.packetpilot.com/cisco-live-us-2019-explorer-guide/
Reading Time: 5 minutesLast year I was involved in assisting a datacenter core and access-layer refresh. In this case the IDF’s were reusing existing fiber patches and the run to the datacenter stayed in place. however, within the datacenter core equipment was placed across the room required new cross connects to be ran to the new core cabinet. When the cutovers began to take place the IDF’s were spread out over a large campus. Meaning troubleshooting by walking back and forth to check cabling was extremely time consuming and inefficient. Since all the IDF’s were connected via port channels I was able to figure out which runs were crossed and go fix them all at once using only the ether channel show output. I’ll walk you through the process now.
Permanent link to this article: https://www.packetpilot.com/remote-troubleshooting-crossed-fiber-using-port-channels/
Reading Time: 3 minutesAs it turns out, albeit I don’t do voice as my career focus, I decided to help out a team member and took ownership of an issue that came up. It was a phone that wasn’t working, one that was attached to an ATA 190. After I tracked down the device I typed it’s IP address into my web browser and found it in a Recovery Firmware state. What us traditional Cisco route/switch guys would consider “ROMMON” as a loose equivalent. In this case it is important to note, since the device wasn’t function on proper firmware and was in recovery mode, the IP address of the ATA is actually in the Data VLAN at this point, NOT the Voice VLAN.
Permanent link to this article: https://www.packetpilot.com/ata-190-recovery-firmware-page-ata-190-will-not-register/
Reading Time: 4 minutes
tl;dr – THANK YOU ALL!
Yesterday morning I opened up my Spark app and was surprised to see I was added to the Cisco Champions room. I checked my e-mail and saw nothing. I knew it was being announced soon do to some twitter chatter. After validating with members it was true. I was selected as a 2017 member of Cisco Champions. I’m going to say I’m blown away even still today. I am absolutely honored to be part of such an amazing group of individuals. It has caused me to sit back and think about how I even came to know the people I look up to. So how did it start?
Permanent link to this article: https://www.packetpilot.com/cisco-champions-2017-a-reason-to-reflect/
Reading Time: 4 minutesThe other week I ran into an instance where a group of customers were unable to access Cisco Unified Intelligence Center. Upon further investigation I was unable to get to admin pages of much of the collaboration suite and call control systems from these users computers either. The suite was on various versions of 9.0.X and 9.1.X due to restraints with many third party integration’s. This issue will occur on anything using the cipher suite mentioned below and is not limited to these versions or applications. This is ultimately where the problem stems from but I’ll take you down the path.
To start I’m going to list the fixes in case you don’t want to read my troubleshooting methodology. Then I will walk you through my discovery and detail the fixes. Remember, which fix is correct for your situation will vary based on use case, security policies, etc.
Fix 1: Uninstall Microsoft Updates causing issue
Fix 2: Re-issue certificate (if possible) using strong ciphers (may require upgrading applications)
Fix 3: Use a different web browser
Fix 4: Re-order ciphers via Group Policy
Permanent link to this article: https://www.packetpilot.com/ms-kb-31616393161608-break-cucm-uccx-web-access/
Reading Time: 4 minutesI 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.
Permanent link to this article: https://www.packetpilot.com/uc-guerrilla-wallboard-on-server-2012-64bit/
By Matt Ouellette in Certification, Cisco, Featured, How To's, LAN Scripts, LAN/WAN, Networking, Real World, Scripts, WAN Scripts
December 10, 2015
December 10, 2015
Reading Time: 3 minutesI’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/
Reading Time: 5 minutesBeing the geek I am, I was troubleshooting an issue one day where I wanted to see what dial-peer a certain digit string was hitting on a gateway. I saw something that simply intrigued my mind that took focus away until I figured it out. This “thing” I saw was irrelevant to what I was troubleshooting but once the problem was resolved I simply had to figure it out. I’m sure many of you experience that same thing throughout your days. So, this is what I’ve discovered. *Please note that this is not an official explanation of the item/output, it is simply my interpretation from time spent figuring out what it really meant.
Permanent link to this article: https://www.packetpilot.com/what-is-that-timestamp-dial-peers-last-setupdisconnect-time/