Well, it’s been quite some years since the original build and even the follow-up rebuild. The original build was when my oldest (turning 13) was 7 and my middle child (turning 10) was 4. They’ve had the same AMD R7 240 graphics cards since then. Unfortunately, the games they play which began as browser based games and minecraft, have upgraded to things like roblox, fortnite, and somehow minecraft’s blocks needs more juice. So here we are. Over labor day, my friend (thanks @ctark) pointed a sale at antonline out to me where they had RTX 2060’s in stock for 224$ each. First, I’ve not seen a graphics card in stock for a long time and second, while 224$ is well over what I might have planned to do for them, I thought it was worth it. Just looking at benchmarks, the new card is effectively almost 1500% better, so I decided to jump in.

It’s been quite a while since my last post, but I wanted to cover something I had tinkered with a few times and finally got to a state I’m ok with. IPv6 in docker containers. For my testing, I will be using linuxserver.io containers, as being part of the team allows me to easily fix anything that prevents full functionality. I guess to start, a big thing I found is most ipv6 guides, including the official documentation, tells you how to enable ipv6 for the default bridge. As we all know, the default bridge is trash, it doesnt work like a custom bridge and causes a number of issues. You may also see guides that lead you to setup nds proxy which works, but it introduces a HUGE amount of latency. When I tested the NDS proxy method, i couldn’t stand how slow it was and quickly reverted the change. So, let’s get into how I set it up, note that I am not claiming to have the best method, the most efficient method, the most secure method or anything of the sort. This is just how I set it up to get what I wanted working in a way I was OK with.

While working with a client this week, I encountered an undocumented bug with secure LDAP authentication. My client was doing an upgrade from CSR11.5 to CSR 12.5 and in conjunction with this upgrade, moving to a new domain and active directory. With these changes, I decided to assist by ensuring they were compliant with Microsoft’s recommendation that secure ldap is used.

WARNING: This post has a lot of pictures! I’ve been meaning to write this up for a while, but I’ve been lazy/busy. As some may know, I relocated with my family from Nashville to Kentucky when my wife accepted her new position. As a consultant, I have the freedom to live and work from anywhere, so moving to improve my wife’s career was no big deal. Fortunately, a new home offers the chance to correct oversights on the last one. One of the first things I did was take the plans and determine how I wanted my network to look. I knew I wanted a collapsed core with access layer devices on each floor. I started by estimating how many wired connections per floor I would want. After this, I segmented those out to determine how many needed POE. The biggest thing was ensuring I left room for growth.

As some of you may know, I’ve documented my IT adventures for over 5 years now. Personally, I think a lot of my articles were pretty useful and I actually referenced them regularly while working on client systems. Sadly, today I had a database failure.

After reading this, look at the bug I discovered when enabling secure LDAP on UC applications [here][1]. As many of you are aware, Microsoft began the process to deprecate LDAP access into Active Directory back in March. You can read cisco’s advisory here: [https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/trouble/12_5_1/fieldNotice/cucm_b_fn-secure-ldap-mandatory-ad.html][2] Basically, this means we need to do a fairly simple swap from LDAP to LDAPS. I just completed one for a client’s CUC and CUCM and it took about 30 minutes start to finish.

I lost a lot of data during a database failure where I also discovered my backups weren’t working. TEST YOUR BACKUPS! I had something about 8192 NAT table limitation here, if that doesn’t bother you, you don’t need to proceed unless you want to. I’ll cover the three methods (I only am aware of these 3) that I tested myself. Dumb switch, EAProxy, and full bypass.

In this article, I discuss how to get root access to Cisco UC Applications, without leveraging TAC. This is NOT a supported process.

While working with a client recently, I had a situation where they had two non-HA cubes connecting to two VeloCloud SDWAN devices to get to the carrier. My first thought was to use OSPF for the routes which would allow for easy failover and a potential use of BFD. However, the carrier informed us that they only use dynamic routing protocols on their upstream connections, and we would need to use static routes to them. My first thought in this case (barring bad thoughts about the carrier) were just using weighted static routes and relying on if the carrier’s interface is down, we would see it down causing the secondary static route to take over. Well, after testing with the carrier, if they shut their port, Cisco saw it up up resulting in 100% packet loss due to the lack of transition for the static route. See the routes below

Sometimes when you’re in a client environment, you just need something you don’t have access to. That could be NTP, DNS, gateways, an internal CA, or even just an SFTP server. I encounter this all the time and my solution is almost always to simply get an IP from the client and spin up a linux server.