Worth Reading: Is Your Consultant a Parasite?

Stumbled upon a must-read article: Is Your Consultant a Parasite?

For an even more snarky take on the subject, enjoy the Ten basic rules for dealing with strategy consultants by Simon Wardley.

Worth Reading: Is Your Consultant a Parasite?

Stumbled upon a must-read article: Is Your Consultant a Parasite?

For an even more snarky take on the subject, enjoy the Ten basic rules for dealing with strategy consultants by Simon Wardley.

Video: Comparing Routing and Bridging

After covering the basics of transparent Ethernet bridging and IP routing, we’re finally ready to compare the two. Enjoy the ride ;)

Video: Comparing Routing and Bridging

After covering the basics of transparent Ethernet bridging and IP routing, we’re finally ready to compare the two. Enjoy the ride ;)

Questions about BGP in the Data Center (with a Whiff of SRv6)

Henk Smit left numerous questions in a comment referring to the Rethinking BGP in the Data Center presentation by Russ White:

In Russ White’s presentation, he listed a few requirements to compare BGP, IS-IS and OSPF. Prefix distribution, filtering, TE, tagging, vendor-support, autoconfig and topology visibility. The one thing I was missing was: scalability.

I noticed the same thing. We kept hearing how BGP scales better than link-state protocols (no doubt about that) and how you couldn’t possibly build a large data center fabric with a link-state protocol… and yet this aspect wasn’t even mentioned.

Questions about BGP in the Data Center (with a Whiff of SRv6)

Henk Smit left numerous questions in a comment referring to the Rethinking BGP in the Data Center presentation by Russ White:

In Russ White’s presentation, he listed a few requirements to compare BGP, IS-IS and OSPF. Prefix distribution, filtering, TE, tagging, vendor-support, autoconfig and topology visibility. The one thing I was missing was: scalability.

I noticed the same thing. We kept hearing how BGP scales better than link-state protocols (no doubt about that) and how you couldn’t possibly build a large data center fabric with a link-state protocol… and yet this aspect wasn’t even mentioned.

Deploying Plug-and-Pray Software in Large-Scale Networks

One of my readers sent me a sad story describing how Chromium service discovery broke a large multicast-enabled network.

The last couple of weeks found me helping a customer trying to find and resolve a very hard to find “network performance” issue. In the end it turned out to be a combination of ill conceived application nonsense and a setup with a too large blast radius/failure domain/fate sharing. The latter most probably based upon very valid decisions in the past (business needs, uniformity of configuration and management).

Deploying Plug-and-Pray Software in Large-Scale Networks

One of my readers sent me a sad story describing how Chromium service discovery broke a large multicast-enabled network.

The last couple of weeks found me helping a customer trying to find and resolve a very hard to find “network performance” issue. In the end it turned out to be a combination of ill conceived application nonsense and a setup with a too large blast radius/failure domain/fate sharing. The latter most probably based upon very valid decisions in the past (business needs, uniformity of configuration and management).

OSPF Inter-Process Route Selection

The traditional wisdom claimed that a Cisco IOS router cannot compare routes between different OSPF routing processes. The only parameter to consider when comparing routes coming from different routing processes is the admin distance, and unless you change the default admin distance for one of the processes, the results will be random.

Following Vladislav’s comment to a decade-old blog post, I decided to do a quick test, and found out that code changes tend to invalidate traditional wisdom. OSPF inter-process route selection is no exception. That’s why it’s so stupid to rely on undefined behavior in your network design, memorize such trivia, test the memorization capabilities in certification labs, or read decades-old blog posts describing arcane behavior.

OSPF Inter-Process Route Selection

The traditional wisdom claimed that a Cisco IOS router cannot compare routes between different OSPF routing processes. The only parameter to consider when comparing routes coming from different routing processes is the admin distance, and unless you change the default admin distance for one of the processes, the results will be random.

Following Vladislav’s comment to a decade-old blog post, I decided to do a quick test, and found out that code changes tend to invalidate traditional wisdom. OSPF inter-process route selection is no exception. That’s why it’s so stupid to rely on undefined behavior in your network design, memorize such trivia, test the memorization capabilities in certification labs, or read decades-old blog posts describing arcane behavior.

ipSpace.net Subscription for System Administrators

One of our subscribers sent me this question:

I am a system administrator working primarily on server/storage virtualization. How would you recommend I take full advantage of the subscription while not being in networking full-time?

Let’s start with the webinars focused on technologies and fundamentals:

• If you’re interested in networking fundamentals, go through the first part of How Networks Really Work — stop when you feel it’s turning into a deep dive.
• As a sysadmin, you probably work within a data center environment. Data Center Infrastructure for Networking Engineers is another fundamentals-focused webinar worth exploring.
• Involved in multi-site DC deployments? Check out the Data Center Interconnects and Designing Active-Active and Disaster Recovery Data Centers.
• On the storage side, there’s Hyper-Converged Infrastructure Deep Dive and The Network Impact of NVMe over Fabrics (NVMe-oF).

ipSpace.net Subscription for System Administrators

One of our subscribers sent me this question:

I am a system administrator working primarily on server/storage virtualization. How would you recommend I take full advantage of the subscription while not being in networking full-time?

Let’s start with the webinars focused on technologies and fundamentals:

• If you’re interested in networking fundamentals, go through the first part of How Networks Really Work — stop when you feel it’s turning into a deep dive.
• As a sysadmin, you probably work within a data center environment. Data Center Infrastructure for Networking Engineers is another fundamentals-focused webinar worth exploring.
• Involved in multi-site DC deployments? Check out the Data Center Interconnects and Designing Active-Active and Disaster Recovery Data Centers.
• On the storage side, there’s Hyper-Converged Infrastructure Deep Dive and The Network Impact of NVMe over Fabrics (NVMe-oF).

Intricate AWS IPv6 Direct Connect Challenges

In his Where AWS IPv6 networking fails blog post, Jason Lavoie documents an intricate consequence of 2-pizza-teams not talking to one another: it’s really hard to get IPv6 in AWS VPC working with Transit Gateway and Direct Connect in large-scale multi-account environment due to the way IPv6 prefixes are propagated from VPCs to Direct Connect Gateway.

It’s one of those IPv6-only little details that you could never spot before stumbling on it in a real-life deployment… and to make it worse, it works well in IPv4 if you did proper address planning (which you can’t in IPv6).

Intricate AWS IPv6 Direct Connect Challenges

In his Where AWS IPv6 networking fails blog post, Jason Lavoie documents an intricate consequence of 2-pizza-teams not talking to one another: it’s really hard to get IPv6 in AWS VPC working with Transit Gateway and Direct Connect in large-scale multi-account environment due to the way IPv6 prefixes are propagated from VPCs to Direct Connect Gateway.

It’s one of those IPv6-only little details that you could never spot before stumbling on it in a real-life deployment… and to make it worse, it works well in IPv4 if you did proper address planning (which you can’t in IPv6).

Worth Reading: The Lost Designer

Scott Berkun published another interesting article: The Lost Designer. As always, replace designer with networking engineer and enjoy.

Worth Reading: The Lost Designer

Scott Berkun published another interesting article: The Lost Designer. As always, replace designer with networking engineer and enjoy.

Lessons Learned: Technology Still Matters

In June 2020, a friend of mine asked me to do a short presentation on lessons learned during my 35 years of being a networking engineer. It went reasonably well, so I decided to turn it into a webinar, starting with regardless of what the disruptive marketers tell you, technology still matters.

Lessons Learned: Technology Still Matters

In June 2020, a friend asked me to do a short presentation on lessons learned during my 35 years as a networking engineer. It went reasonably well, so I decided to turn it into a webinar, starting with regardless of what the disruptive marketers tell you, technology still matters.

Unnumbered Ethernet Interfaces, DHCP Edition

Last week we explored the basics of unnumbered IPv4 Ethernet interfaces, and how you could use them to save IPv4 address space in routed access networks. I also mentioned that you could simplify the head-end router configuration if you’re using DHCP instead of per-host static routes.

Obviously you’d need a smart DHCP server/relay implementation to make this work. Simplistic local DHCP server would allocate an IP address to a client requesting one, send a response and move on. Likewise, a DHCP relay would forward a DHCP request to a remote DHCP server (adding enough information to allow the DHCP server to select the desired DHCP pool) and forward its response to the client.

Unnumbered Ethernet Interfaces, DHCP Edition

Last week we explored the basics of unnumbered IPv4 Ethernet interfaces, and how you could use them to save IPv4 address space in routed access networks. I also mentioned that you could simplify the head-end router configuration if you’re using DHCP instead of per-host static routes.

Obviously you’d need a smart DHCP server/relay implementation to make this work. Simplistic local DHCP server would allocate an IP address to a client requesting one, send a response and move on. Likewise, a DHCP relay would forward a DHCP request to a remote DHCP server (adding enough information to allow the DHCP server to select the desired DHCP pool) and forward its response to the client.