gurfin gurf1n

Ever wanted to try being your own ISP? Ever wanted to setup a transit AS while hosting some services on IP-addresses you own? Enter “dn42” (https://dn42.eu/), where you are able to build an overlay network of software or hardware based routers and do BGP peering with hundreds of other AS:s. For a couple of months now I have been itching to setup a dn42 network to learn some more about software based routing and networking in the cloud.

I have a special appreciation for the multicast technology. Back when I used to work in first line support for a Swedish service provider of IPTV, I was always intrigued by the efficiency of using multicast to deliver the TV to peoples homes. Using multicast drastically reduced the bandwidth requirements for the central streaming sources that were used to send out the TV broadcasts onto the fiber networks. Now, in recent years service providers have moved away from this and into using unicast streaming in stead.

A project I have recently undertaken requires me to use linux based routing processes to communicate with other peers. The software I have chosen to run is bird2, which allows me to establish adjacencies with and BGP peer, Cisco or other. I have noticed however, that I find myself google:ing the same commands over and over again. So I though I would collect all the commands I have found to be useful in a blog post, that I myself can refer back to.

Summer and winter time adjustments is something that causes quite the headache when you want all your devices to have an accurate clock. This is especially important when you are going to review logs. I will therefore share a short snippet of config which can be used to set the clock of a Cisco IOS-XE device to correctly adapt to the summer/winter time. clock timezone SWEDEN 1 0 clock summer-time SUMMERTIME recurring last Sun Mar 3:00 last Sun Oct 3:00 In order to also display log entries with the correct timestamp you need to add the following command:

I have been doing this blog now for the past year, admittedly with varying intervals between posts. Reflecting on everything I have written is becomes apparent how my interest and focus has wandered around during the last year. Everything from traditional routing on Cisco platforms and MPLS, to building CI/CD pipelines and deploying applications to the cloud. There are a few posts that I feel have been especially important this past year.

The fiber guide It’s quite common for network engineers not to be as familiar with the hardware side of networking. One of the most common hardware questions I get is about optical network links, something that has become the new standard for network interconnects. So I figured I would do a writeup on the optics topic. Back to basics The goal of a data transfer is to communicate some type of data across distance.

BGP Path selection One of the most essential parts of BGP is its path selection algorithm. It dictates how BGP is to select which paths to promote to the RIB. Using the different Path attributes you can affect how routing of your prefixes is done within your network, in your peers network and even on the internet. The path selection is done in a ascending order, where the first unequal attribute will be the determinator of which path is selected.

Big Gaming Protocol The big bad Border Gateway Protocol (BGP) is, unlike the OSPF, EIGRP and ISIS, an eBGP designed to connect together large scale networks. Because BGP is built for scale, it is tuned to be a bit more stable than the IGPs. For example it does not allow for dynamic neighbor discovery, but rather each neighbor must be explicitly specified. The BGP hold timers are also a lot more generous than the IGP timers, with the default being 3 minutes.

Building an IaC BIND9 DNS deployment on kubernetes For some time now I have been displeased with my DNS server setup. Previously I have had a single Pi-hole instance running on a Raspberry Pi at one of my sites. This means that private DNS resolution, for the entire network, was dependent on a single site and a single compute node. This Single Point of Failure (SPoF) is not something i was to happy with, and I did not want to point all my client networks to a singular Raspberry Pi.

OSPF version 3 To support IPv6 routing, OSPF version 3 (OSPFv3) was created. It has support for both IPv4 and IPv6, but is not backwards compatible with the version 2 standard. In fact, the protocol is designed to be independent on the address family type. The communication between routers is based entirely on IPv6 though, using link-local addresses. There is also support for multiple instances within a network, which allows you to configure which routers are able to form adjacencies.