Update

The remote hands at the data center installed the new NICs on Friday. I was hoping iDRAC would be configured with DHCP so it would get an IP, but that wasn’t the case. Fortunately, the remote hands updated the DHCP setting for me. After that, I was able to remote in and install FreeBSD.

Next, I need to set up some MLAG ports on the switch and prepare to migrate from the VM router to this router. I have OOB access to it, which will help prevent me from getting locked out since I manage the network remotely.

The second phase of our update is complete. We’ve accomplished the following items:

• Upgraded the switches’ firmware
• Established MLAG between the two switches
• Added independent transit to both switches
• Set up the XC for most of our IX
• Configured all the VLANs

While we have achieved a lot, there is still work to do:

• Configure the R630 as a router running FreeBSD and BIRD
• Plan the migration from a VM router to the new router
• Purchase another server to run Proxmox so we can provide high availability

Migration

We migrated our servers to our very own cabinet inside 1530 Swift!

Having our own cabinet required us to purchase some switches, so we picked up a few Arista switches: two 7050SX and one 7010T for OOB.

The migration went surprisingly well. We did some preparation before the server was moved, and when it was powered on, everything came back online.

Our connections to the exchanges haven’t been restored yet, as they’re still running the required cross-connects.

We ordered some new hardware for our core router in Kansas City, MO. This new router will increase stability, security, and performance.

After we get our new router installed, we will be joining the Seattle IX via the NOCIX extension.

This week we finished moving our primary hypervisor to Kansas City, MO. This gives us greater control over our infrastucture and what we can offer.

We’re also in the process of connecting to MICE!

This week we will be updating our core infrastructure in Kansas City, MO.

We just setup a looking glass using bgp.tools!

I believe I’m using a pretty standard PathVector config, but I keep running into issues.

• HyeHost IPv6 Upstream can’t connect
• No IPv6 routes work
• Hurricane Electric IPv6 transit won’t work
• Tritan IPv6 transit won’t work

I suspect it has something to do with my IRR. The current version of my IRR is below. It can be frustrating to troubleshoot something that takes time to propagate.

aut-num:        AS46733
as-name:        X6C
descr:          P.O. Box 148
                Teays Valley WV 25569
                United States
member-of:      AS46733:AS-X6C
import:         from AS-X6C-UPSTREAM accept ANY
mp-import:      afi ipv6 from AS-X6C-UPSTREAM accept ANY
export:         to AS-ANY announce AS46733:AS-X6C
export:         to AS-X6C-UPSTREAM announce AS46733:AS-X6C
mp-export:      afi ipv6 to AS-ANY announce AS46733:AS-X6C
mp-export:      afi ipv6 to AS-X6C-UPSTREAM announce AS46733:AS-X6C
admin-c:        DURFE12-ARIN
tech-c:         NETWO9987-ARIN
mnt-by:         MNT-XL-116
created:        2024-08-31T13:40:44Z
last-modified:  2024-08-31T13:40:44Z
source:         ARIN

Troubleshooting

Troubleshooting these issues has taught me some helpful commands.

We’ve been running into a couple of issues where our peering sessions go down. It’s not a major issue, but we’re going to be working on stability. Also, we’ve noticed occasional issues with IPv4 on some servers and IPv6 on others.

Our peering db page is more accurate now since we started sharing our sessions directly with them.

As we build our network we continue to monitor the uptime of each node and that provider. This data will help us make longterm decisions reguarding who we rely on for our upstream.

We’ve already seen our providers dealing with a couple of issues. While we understand things happen, how the provider handles issues is what we consider most important.

Please refer to the pops page for an updated list of our points of presence.