Recently, I posted about swapping to 2G service which would move me from alt-optic gpon to xgs-pon and then allow me to fully bypass the ATT ont and not even use 802.11x configuration. I thought it was pretty detailed, but I was asked about some of the outputs during the setup. Fortunately, I kept the notes in my notepad instance and can expand on things. This is an addendum to the original article here.
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.
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
Today, I was working with a client at a remote location. Initially, we prepped a Cisco 4331 to be installed as an SRST-CME device. This particular site has a PRI and a relatively unstable WAN connection. I prepped this router in a different location as we expected no WAN connection once it was installed. As it turned out, the PRI got turned up much earlier than expected, so now we needed to get the phones registered to the router. Well, as some of you may know, you can’t configure a router for SRST-CME AND CME at the same time. Thus begins the process of removing the SRST-CME config and prepping the new config.