nyechiel · nyechiel · Feb 12, 2026 · Feb 12, 2026
diff --git a/_posts/2014-11-30-the-need-for-network-overlays-part-ii.md b/_posts/2014-11-30-the-need-for-network-overlays-part-ii.md
@@ -17,7 +17,7 @@ comments_id: 4
 permalink: "/blog/2014/11/30/the-need-for-network-overlays-part-ii/"
 redirect_from: "/2014/11/30/the-need-for-network-overlays-part-ii/"
 ---
-In the [previous post](/2014/07/01/the-need-for-network-overlays-part-i/), I covered some of the basic concepts behind network overlays, primarily highlighting the need to move into a more robust, L3 based, network environments. In this post I would like to cover network overlays in more detail, going over the different encapsulation options and highlighting some of the key points to consider when deploying an overlay-based solution.
+In the [previous post](/blog/2014/07/01/the-need-for-network-overlays-part-i/), I covered some of the basic concepts behind network overlays, primarily highlighting the need to move into a more robust, L3 based, network environments. In this post I would like to cover network overlays in more detail, going over the different encapsulation options and highlighting some of the key points to consider when deploying an overlay-based solution.
 
 ## Underlying fabric considerations
 

diff --git a/...23-ipv6-prefix-delegation-what-is-it-and-how-does-it-going-to-help-openstack.md b/...23-ipv6-prefix-delegation-what-is-it-and-how-does-it-going-to-help-openstack.md
@@ -13,7 +13,7 @@ comments_id: 10
 permalink: "/blog/2015/06/23/ipv6-prefix-delegation-what-is-it-and-how-does-it-going-to-help-openstack/"
 redirect_from: "/2015/06/23/ipv6-prefix-delegation-what-is-it-and-how-does-it-going-to-help-openstack/"
 ---
-IPv6 offers several ways to assign IP addresses to end hosts. Some of them (SLAAC, stateful DHCPv6, stateless DHCPv6) were already covered in [this post](/2014/07/02/ipv6-address-assignment-stateless-stateful-dhcp-oh-my/). The IPv6 Prefix Delegation mechanism (described in [RFC 3769](https://tools.ietf.org/html/rfc3769) and [RFC 3633](https://www.ietf.org/rfc/rfc3633.txt)) provides “a way of automatically configuring IPv6 prefixes and addresses on routers and hosts” - which sounds like yet another IP assignment option. How does it differ from the other methods? And why do we need it? Let’s try to figure it out.
+IPv6 offers several ways to assign IP addresses to end hosts. Some of them (SLAAC, stateful DHCPv6, stateless DHCPv6) were already covered in [this post](/blog/2014/07/02/ipv6-address-assignment-stateless-stateful-dhcp-oh-my/). The IPv6 Prefix Delegation mechanism (described in [RFC 3769](https://tools.ietf.org/html/rfc3769) and [RFC 3633](https://www.ietf.org/rfc/rfc3633.txt)) provides “a way of automatically configuring IPv6 prefixes and addresses on routers and hosts” - which sounds like yet another IP assignment option. How does it differ from the other methods? And why do we need it? Let’s try to figure it out.
 
 ## Understanding the problem
 

diff --git a/...015-12-29-reflections-on-the-networking-industry-part-2-on-cli-apis-and-snmp.md b/...015-12-29-reflections-on-the-networking-industry-part-2-on-cli-apis-and-snmp.md
@@ -18,7 +18,7 @@ comments_id: 13
 permalink: "/blog/2015/12/29/reflections-on-the-networking-industry-part-2-on-cli-apis-and-snmp/"
 redirect_from: "/2015/12/29/reflections-on-the-networking-industry-part-2-on-cli-apis-and-snmp/"
 ---
-In the [previous post](/2015/12/28/reflections-on-the-networking-industry-part-1/) I briefly described the fact that many networks today are closed and vertically designed. While standard protocols are being adopted by vendors, true interoperability is still a challenge. Sure, you can bring up a BGP peer between platforms from different vendors and exchange route information (otherwise we couldn’t scale the Internet), but management and configuration is still, in most cases, vendor specific.
+In the [previous post](/blog/2015/12/28/reflections-on-the-networking-industry-part-1/) I briefly described the fact that many networks today are closed and vertically designed. While standard protocols are being adopted by vendors, true interoperability is still a challenge. Sure, you can bring up a BGP peer between platforms from different vendors and exchange route information (otherwise we couldn’t scale the Internet), but management and configuration is still, in most cases, vendor specific.
 
 Every network engineer out there got to respect the [CLI](https://en.wikipedia.org/wiki/Command-line_interface). We sometimes love them and sometimes hate them, but we all tend to master them. The glorious way of interacting with a network device, even in 2015. Some common properties of CLIs are:
 

diff --git a/_posts/2016-01-04-lldp-traffic-and-linux-bridges.md b/_posts/2016-01-04-lldp-traffic-and-linux-bridges.md
@@ -15,7 +15,7 @@ comments_id: 15
 permalink: "/blog/2016/01/04/lldp-traffic-and-linux-bridges/"
 redirect_from: "/2016/01/04/lldp-traffic-and-linux-bridges/"
 ---
-In my [previous post](/2015/12/31/hands-on-with-fedora-kvm-and-cumulus-vx/) I described my Cumulus VX lab environment which is based on Fedora and KVM. One of the first things I noticed after bringing up the setup is that although I have got L3 connectivity between the emulated Cumulus switches, I can’t get [LLDP](http://www.ieee802.org/1/pages/802.1ab.html) to operate properly between the devices. 
+In my [previous post](/blog/2015/12/31/hands-on-with-fedora-kvm-and-cumulus-vx/) I described my Cumulus VX lab environment which is based on Fedora and KVM. One of the first things I noticed after bringing up the setup is that although I have got L3 connectivity between the emulated Cumulus switches, I can’t get [LLDP](http://www.ieee802.org/1/pages/802.1ab.html) to operate properly between the devices. 
 
 For example, a basic ICMP ping between the directly connected interfaces of leaf1 and spine3 is successful, but no LLDP neighbor shows up:
 <blockquote>

diff --git a/_posts/2020-04-12-hello-again-red-hat.md b/_posts/2020-04-12-hello-again-red-hat.md
@@ -15,7 +15,7 @@ redirect_from: "/2020/04/12/hello-again-red-hat/"
 ---
 _tl;dr - as of February 2020, I am back at Red Hat, focusing on OpenShift multi-cluster networking_.
 
-2020 brings a new beginning for me. Last year I [decided to join the Connectivity team at Facebook](/2019/04/23/a-new-beginning/). Working at Facebook was a great experience for me, but after a few months there I realized that I was not happy and this is not going to be a long-term fit for me. In August, I made the decision to quit and go and spend some well-needed time with my family. I was happily funemployed for around 4 months, and it was just awesome!
+2020 brings a new beginning for me. Last year I [decided to join the Connectivity team at Facebook](/blog/2019/04/23/a-new-beginning/). Working at Facebook was a great experience for me, but after a few months there I realized that I was not happy and this is not going to be a long-term fit for me. In August, I made the decision to quit and go and spend some well-needed time with my family. I was happily funemployed for around 4 months, and it was just awesome!
 
 Starting with February 2020, I am back at Red Hat, supporting the OpenShift multi-cluster network engineering team. Transitioning from Product Management to engineering (and engineering management in particular) is new to me, but I enjoy every second of it so far.
 

diff --git a/robots.txt b/robots.txt
@@ -0,0 +1,7 @@
+User-agent: *
+Allow: /
+
+Disallow: /assets/
+Disallow: /redirects.json
+
+Sitemap: https://nyechiel.com/sitemap.xml
diff --git a/sitemap.xml b/sitemap.xml
@@ -37,7 +37,7 @@ sitemap:
         {% assign is_redirect = true %}
       {% endif %}
     {% endif %}
-    {% unless page.sitemap.exclude == "yes" or page.name == "feed.xml" or is_redirect %}
+    {% unless page.sitemap.exclude == "yes" or page.url == "/feed.xml" or page.url == "/404/" or page.url == "/redirects.json" or page.url contains "/assets/" or is_redirect %}
     <url>
       <loc>{{ site.url }}{{ page.url | remove: "index.html" }}</loc>
       {% if page.sitemap.lastmod %}