Migration to Hugo

I have migrated this 14-year-old blog from a dynamic WordPress (based on WordPress) to a static website (based on Hugo). It was a pretty lengthy process even when I had scripts converting the WordPress XML export into markdown files.

Why a static site?

This gives a few advantages like:

• Must faster rendering as all the pages are generated well in advance & pushed to the server
• Better security (as the backend is not at all exposed unlike WordPress where backend admin portal was visible & behind an authenticated URL)
• Easy to distribute and put behind CDN
• Easy to type posts as now it’s just markdown

I haven’t finalised the hosting location for this newer site. For now, it’s on Google Cloud firebase but I am still just playing with the options. If I get some free time, I might just tweak my PowerDNS setup to start using GeoIP data for the request and serve the local server in a given country. That way I can host the website in India, Europe and US and let authoritative DNS steer the traffic. More on this later!

I was having this discussion with someone recently on possible software to manage an IXP. Lately, IXP Manager has become the de-facto choice for managing IX. It’s a good tool. Nick and INEX team has built a fantastic open-source tool. But I still feel it’s a bit overloaded for a small 1-2 DC IX operation.

If I have to set up a small to mid-size IX, I would rather do that with arouteserver instead of IXP Manager as I did in case of BharatIX in Mumbai (until it shutdown!). One of the problems with arouteserver is that it can be script intensive and one may need something around it to manage it for things like build config on clients.yml update, regularly update filters etc.

Next week SANOG (South Asia Network Operator Group) event will start in Kathmandu, Nepal. I will be instructing on a 4-day workshop on Network Automation with two fellow instructors. The idea of this workshop is to make fellow Ops / Network engineers familiar with concepts of Docker, Ansible, and Gitlab CI/CD pipeline and ultimately to make use of REST APIs to bind these all together.

This is the first time I am doing such a workshop and the content here is built from scratch. On the positive side, it gives good flexibility on content but the challenge is to stick on time. Since content is not tested before, there will always be a risk of going “too slow” or “too fast”. The goal by the end of the workshop is to ensure that attendees can build up event-driven automation. They should be able to set up a system where “if x happens” then “action y is triggered”. This can fit a wide variety of use cases.

As returning readers of this blog would be aware - I found a trick to find Facebook caching servers around the world during the APRICOT 2018 hackathon. Since then I am running my code again every year to see the changes and publish this report.

Previous reports

1. March 2018 here
2. Nov 2019 here
3. April 2021 here

Facebook knows!

Back in 2019, I was in San Francisco, California for NANOG 75. While roaming around in the lobby, someone read the NANOG card hanging around my neck and greeted me. His 2nd line after greeting was “Oh I know that name, you are the guy who mapped our caching nodes” and we both laughed. I must say this specific category of the post has brought some attention around.

In a recent Network AF podcast Avi Freedman (Kentik) joked with the guest about how he finds who is transit free / tier 1 network. He said, “I ask everyone who they think is a tier 1 network. Everyone includes their own name + other names”. Next, he ignores the self-nomination & looks at the common list to find who actually is a tier 1 network. This is funny, intuitive and gives some clue.