Thank You for Everything Irena, We’ll Miss You Badly

In February 2018, Irena Marčetič joined ipSpace.net to fix the (lack of) marketing. After getting that done, she quickly took over most of sales, support, logistics, content production, guest speaker coordination… If you needed anything from us in the last few years, it was probably Irena answering your requests and helping you out.

She did a fantastic job and transformed ipSpace.net from Ivan and an occasional guest speaker to a finely tuned machine producing several hours of new content every month. She organized our courses, worked with guest speakers, podcast guests and hosts, participated in every guest speaker webinar to take notes for the editing process, managed content editing, watched every single video we created before it was published to make sure the audio was of acceptable quality and all the bloopers were removed… while answering crazy emails like I need you to fill in this Excel spreadsheet with your company data because I cannot copy-paste that information from your web site myself and solving whatever challenges our customers faced.

Unfortunately, Irena decided to go back to pure marketing and is leaving ipSpace.net today. Thanks a million for all the great work – we’ll badly miss you.

Thank You for Everything Irena, We’ll Miss You Badly

In February 2018, Irena Marčetič joined ipSpace.net to fix the (lack of) marketing. After getting that done, she quickly took over most of sales, support, logistics, content production, guest speaker coordination… If you needed anything from us in the last few years, it was probably Irena answering your requests and helping you out.

She did a fantastic job and transformed ipSpace.net from Ivan and an occasional guest speaker to a finely tuned machine producing several hours of new content every month. She organized our courses, worked with guest speakers, podcast guests and hosts, participated in every guest speaker webinar to take notes for the editing process, managed content editing, watched every single video we created before it was published to make sure the audio was of acceptable quality and all the bloopers were removed… while answering crazy emails like I need you to fill in this Excel spreadsheet with your company data because I cannot copy-paste that information from your web site myself and solving whatever challenges our customers faced.

Unfortunately, Irena decided to go back to pure marketing and is leaving ipSpace.net today. Thanks a million for all the great work – we’ll badly miss you.

Webinars in the First Half of 2021

It’s time for another this is what we did in the last six months blog post. Instead of writing another wall-of-text, I just updated the one I published in early January. Here are the highlights:

• Completed webinars: Kubernetes Networking Deep Dive, Cisco ACI Deep Dive
• Totally unplanned: AI/ML in Networking
• New content in existing webinars: NSX-T Federation, Leaf-and-Spine routing designs, deep dive into reliability theory, AWS Gateway Load Balancer and Network Firewall, Azure Virtual WAN, multi-vendor data center EVPN deployments, networking part of Introduction to Cloud Computing webinar.
• Updated content: configuration and state management automation tools.
• Work-in-progress: Network Automation Concepts

That’s about it for the first half of 2021. I’ll be back in early September.

Webinars in the First Half of 2021

It’s time for another this is what we did in the last six months blog post. Instead of writing another wall-of-text, I just updated the one I published in early January. Here are the highlights:

• Completed webinars: Kubernetes Networking Deep Dive, Cisco ACI Deep Dive
• Totally unplanned: AI/ML in Networking
• New content in existing webinars: NSX-T Federation, Leaf-and-Spine routing designs, deep dive into reliability theory, AWS Gateway Load Balancer and Network Firewall, Azure Virtual WAN, multi-vendor data center EVPN deployments, networking part of Introduction to Cloud Computing webinar.
• Updated content: configuration and state management automation tools.
• Work-in-progress: Network Automation Concepts

That’s about it for the first half of 2021. I’ll be back in early September.

Worth Reading: Blog About What You’ve Struggled With

Some of the best blog posts I’ve read described a solution (and the process to get there) someone reached after a lot of struggle.

As always, Julia Evans does a wonderful job explaining that in exquisite details.

Worth Reading: Blog About What You’ve Struggled With

Some of the best blog posts I’ve read described a solution (and the process to get there) someone reached after a lot of struggle.

As always, Julia Evans does a wonderful job explaining that in exquisite details.

Worth Reading: How to Miss a Deadline

TL&DR: If you’re about to miss a deadline, be honest about it, and tell everyone well in advance.

I wish some of the project managers I had the “privilege” of working with would use 1% of that advice.

How to Miss a Deadline

Worth Reading: How to Miss a Deadline

TL&DR: If you’re about to miss a deadline, be honest about it, and tell everyone well in advance.

I wish some of the project managers I had the “privilege” of working with would use 1% of that advice.

How to Miss a Deadline

Video: Typical Large-Scale Bridging Use Cases

In the previous video in the Switching, Routing and Bridging section of How Networks Really Work webinar we compared transparent bridging with IP routing. Not surprisingly (given my well-known bias toward stable solutions) I recommended using IP routing as much as possible, but there are still people out there pushing large-scale transparent bridging solutions.

In today’s video we’ll look at some of the supposed use cases and stable solutions you could use instead of stretching a virtual thick yellow cable halfway across a continent.

Video: Typical Large-Scale Bridging Use Cases

In the previous video in the Switching, Routing and Bridging section of How Networks Really Work webinar we compared transparent bridging with IP routing. Not surprisingly (given my well-known bias toward stable solutions) I recommended using IP routing as much as possible, but there are still people out there pushing large-scale transparent bridging solutions.

In today’s video we’ll look at some of the supposed use cases and stable solutions you could use instead of stretching a virtual thick yellow cable halfway across a continent.

Stretched VLANs: What Problem Are You Trying to Solve?

One of ipSpace.net subscribers sent me this interesting question:

I am the network administrator of a small data center network that spans 2 buildings. The main building has a pair of L2/L3 10G core switches. The second building has a stack of access switches connected to the main building with 10G uplinks. This secondary datacenter has got some ESX hosts and NAS for remote backup and some VM for development and testing, but all the Internet connection, firewall and server are in the main building.

There is no routing in the secondary building and most of the VLANs are stretched. Do you think I must change that (bringing routing to the secondary datacenter), or keep it simple like it is now?

As always, it depends, this time on what problem are you trying to solve?

Stretched VLANs: What Problem Are You Trying to Solve?

One of ipSpace.net subscribers sent me this interesting question:

I am the network administrator of a small data center network that spans 2 buildings. The main building has a pair of L2/L3 10G core switches. The second building has a stack of access switches connected to the main building with 10G uplinks. This secondary datacenter has got some ESX hosts and NAS for remote backup and some VM for development and testing, but all the Internet connection, firewall and server are in the main building.

There is no routing in the secondary building and most of the VLANs are stretched. Do you think I must change that (bringing routing to the secondary datacenter), or keep it simple like it is now?

As always, it depends, this time on what problem are you trying to solve?

Why Do We Need BGP-LS?

One of my readers sent me this interesting question:

I understand that an SDN controller needs network topology information to build traffic engineering paths with PCE/PCEP… but why would we use BGP-LS to extract the network topology information? Why can’t we run OSPF with controller by simulating a software based OSPF instance in every area to get topology view?

There are several reasons to use BGP-LS:

Why Do We Need BGP-LS?

One of my readers sent me this interesting question:

I understand that an SDN controller needs network topology information to build traffic engineering paths with PCE/PCEP… but why would we use BGP-LS to extract the network topology information? Why can’t we run OSPF with controller by simulating a software based OSPF instance in every area to get topology view?

There are several reasons to use BGP-LS:

Unexpected Interactions Between OSPF and BGP

It started with an interesting question tweeted by @pilgrimdave81

I’ve seen on Cisco NX-OS that it’s preferring a (ospf->bgp) locally redistributed route over a learned EBGP route, until/unless you clear the route, then it correctly prefers the learned BGP one. Seems to be just ooo but don’t remember this being an issue?

Ignoring the “why would you get the same route over OSPF and EBGP, and why would you redistribute an alternate copy of a route you’re getting over EBGP into BGP” aspect, Peter Palúch wrote a detailed explanation of what’s going on and allowed me to copy into a blog post to make it more permanent:

Unexpected Interactions Between OSPF and BGP

It started with an interesting question tweeted by @pilgrimdave81

I’ve seen on Cisco NX-OS that it’s preferring a (ospf->bgp) locally redistributed route over a learned EBGP route, until/unless you clear the route, then it correctly prefers the learned BGP one. Seems to be just ooo but don’t remember this being an issue?

Ignoring the “why would you get the same route over OSPF and EBGP, and why would you redistribute an alternate copy of a route you’re getting over EBGP into BGP” aspect, Peter Palúch wrote a detailed explanation of what’s going on and allowed me to copy into a blog post to make it more permanent:

Comparing EVPN with Flood-and-Learn Fabrics

One of ipSpace.net subscribers sent me this question after watching the EVPN Technical Deep Dive webinar:

Do you have a writeup that compares and contrasts the hardware resource utilization when one uses flood-and-learn or BGP EVPN in a leaf-and-spine network?

I don’t… so let’s fix that omission. In this blog post we’ll focus on pure layer-2 forwarding (aka bridging), a follow-up blog post will describe the implications of adding EVPN IP functionality.

Comparing EVPN with Flood-and-Learn Fabrics

One of ipSpace.net subscribers sent me this question after watching the EVPN Technical Deep Dive webinar:

Do you have a writeup that compares and contrasts the hardware resource utilization when one uses flood-and-learn or BGP EVPN in a leaf-and-spine network?

I don’t… so let’s fix that omission. In this blog post we’ll focus on pure layer-2 forwarding (aka bridging), a follow-up blog post will describe the implications of adding EVPN IP functionality.

Worth Reading: Machine Learning Deserves Better Than This

This article is totally unrelated to networking, and describes how medical researchers misuse machine learning hype to publish two-column snake oil. Any correlation with AI/ML in networking is purely coincidental.

Machine Learning Deserves Better Than This

Worth Reading: Machine Learning Deserves Better Than This

This article is totally unrelated to networking, and describes how medical researchers misuse machine learning hype to publish two-column snake oil. Any correlation with AI/ML in networking is purely coincidental.

Machine Learning Deserves Better Than This