Archive

Category Archives for "ipSpace.net"

Dealing with Cloud Challenges

Here’s a message I got from one of my subscribers (probably based on one of my recent public cloud rants):

I often think the cloud stuff has been sent to try us in IT – the struggle could be tough enough when we were dealing with waterfall development and monolithic projects. When products took years to develop, and years to understand.

And now we’re being asked to be agile and learn new stuff all the time about moving targets that barely have documentation at all, never mind accurate doco! We had obviously got into our comfort zone and needed shaking out of it!

Always interested to hear your experiences with the cloud networking though – it’s what I subscribed to ipspace.net for TBH as I think it’s the most complete reference source for that purpose and a vital part of enterprise networking these days!

It’s always extremely nice to hear someone finds your work valuable ;) Thanks a million!

netsim-tools: Release 0.4 Is Out

TL&DR: The new release of netsim-tools includes unnumbered interfaces, configuration modules, and OSPF configuration.

In mid-March, we enjoyed another excellent presentation by Dinesh Dutt, this time focused on running OSPF in leaf-and-spine fabrics. He astonished me when he mentioned unnumbered Ethernet interfaces being available on all major network operating systems. It was time to test things out, and I wanted to use my networking simulation builder to build the test lab.

netsim-tools: Unnumbered Interfaces, Configuration Modules, OSPF

TL&DR: The new release of netsim-tools includes unnumbered interfaces, configuration modules, and OSPF configuration.

In mid-March, we enjoyed another excellent presentation by Dinesh Dutt, this time focused on running OSPF in leaf-and-spine fabrics. He astonished me when he mentioned unnumbered Ethernet interfaces being available on all major network operating systems. It was time to test things out, and I wanted to use my networking simulation builder to build the test lab.

Interview: Will AI Replace the Networking Engineers?

In the second half of my chat with David Bombal we focused on automation and AI in networking. Even though we discussed many things, including the dangers of doing a repeatable job, and how to make yourself unique, David chose a nice click-bait headline Will AI Replace the Networking Engineers?. According to Betteridge’s law of headlines the answer is still NO, but it’s obvious AI will replace the low-level easy-to-automate jobs (as textile workers found out almost 200 years ago).

While pondering that statement, keep in mind that AI is more than just machine learning (the overhyped stuff). According to one loose definition, “Artificial intelligence (AI) refers to the simulation of human intelligence in machines that are programmed to think like humans and mimic their actions

Full disclosure: the web site with this definition had and ad for Lego Friends set next to it, making it extra-trusty. I couldn’t find a similarly oversimplified definition on Wikipedia… probably for a good reason.

Interview: Will AI Replace the Networking Engineers?

In the second half of my chat with David Bombal we focused on automation and AI in networking. Even though we discussed many things, including the dangers of doing a repeatable job, and how to make yourself unique, David chose a nice click-bait headline Will AI Replace the Networking Engineers?. According to Betteridge’s law of headlines the answer is still NO, but it’s obvious AI will replace the low-level easy-to-automate jobs (as textile workers found out almost 200 years ago).

While pondering that statement, keep in mind that AI is more than just machine learning (the overhyped stuff). According to one loose definition, “Artificial intelligence (AI) refers to the simulation of human intelligence in machines that are programmed to think like humans and mimic their actions

Full disclosure: the web site with this definition had and ad for Lego Friends set next to it, making it extra-trusty. I couldn’t find a similarly oversimplified definition on Wikipedia… probably for a good reason.

Relative Speed of Public Cloud Orchestration Systems

When I was complaining about the speed (or lack thereof) of Azure orchestration system, someone replied “I tried to do $somethingComplicated on AWS and it also took forever

Following the “opinions are great, data is better” mantra (as opposed to “never let facts get in the way of a good story” supposedly practiced by some podcasters), I decided to do a short experiment: create a very similar environment with Azure and AWS.

I took simple Terraform deployment configuration for AWS and Azure. Both included a virtual network, two subnets, a route table, a packet filter, and a VM with public IP address. Here are the observed times:

Relative Speed of Public Cloud Orchestration Systems

When I was complaining about the speed (or lack thereof) of Azure orchestration system, someone replied “I tried to do $somethingComplicated on AWS and it also took forever

Following the “opinions are great, data is better” mantra (as opposed to “never let facts get in the way of a good story” supposedly practiced by some podcasters), I decided to do a short experiment: create a very similar environment with Azure and AWS.

I took simple Terraform deployment configuration for AWS and Azure. Both included a virtual network, two subnets, a route table, a packet filter, and a VM with public IP address. Here are the observed times:

Hands-On: Azure Route Server

TL&DR: Azure Route Server works as advertised. Setting it up is excruciatingly slow. You might want to start the process just before taking a long lunch break.

I decided to take Azure Route Server for a ride. Simple setup, two Networking Virtual Appliance (NVA) instances running Quagga to advertise a single prefix (just to see how multipathing works).

Here’s the diagram of what I set up:

Hands-On: Azure Route Server

TL&DR: Azure Route Server works as advertised. Setting it up is excruciatingly slow. You might want to start the process just before taking a long lunch break.

I decided to take Azure Route Server for a ride. Simple setup, two Networking Virtual Appliance (NVA) instances running Quagga to advertise a single prefix (just to see how multipathing works).

Here’s the diagram of what I set up:

Unequal-Cost Multipath in Link State Protocols

TL&DR: You get unequal-cost multipath for free with distance-vector routing protocols. Implementing it in link state routing protocols is an order of magnitude more CPU-consuming.

Continuing our exploration of the Unequal-Cost Multipath world, why was it implemented in EIGRP decades ago, but not in OSPF or IS-IS?

Ignoring for the moment the “does it make sense” dilemma: finding downstream paths (paths strictly shorter than the current best path) is a side effect of running distance vector algorithms.

For a more formal discussion of loop-free alternates and downstream paths, please read RFC 5714 and RFC 5286.

Unequal-Cost Multipath in Link State Protocols

TL&DR: You get unequal-cost multipath for free with distance-vector routing protocols. Implementing it in link state routing protocols is an order of magnitude more CPU-consuming.

Continuing our exploration of the Unequal-Cost Multipath world, why was it implemented in EIGRP decades ago, but not in OSPF or IS-IS?

Ignoring for the moment the “does it make sense” dilemma: finding downstream paths (paths strictly shorter than the current best path) is a side effect of running distance vector algorithms.

For a more formal discussion of loop-free alternates and downstream paths, please read RFC 5714 and RFC 5286.

There’s No Recipe for Success

TL&DR: There cannot be a simple and easy recipe for success, or everyone else would be using it.

My recent chat with David Bombal about networking careers' future resulted in tons of comments, including a few complaints effectively saying I was pontificating instead of giving out easy-to-follow recipes. Here’s one of the more polite ones:

No tangible solutions given, no path provided, no actionable advice detailed.

I totally understand the resentment. Like a lot of other people, I spent way too much time looking for recipes for success. It was tough to admit there are none for a simple reason: if there was a recipe for easy success, everyone would be using it, and then we’d have to redefine success. Nobody would admit that being average is a success, or as Jeroen van Bemmel said in his LinkedIn comment:

Success requires differentiation, which cannot be achieved by copying others. As Steve Jobs put it: “Be hungry, stay foolish”

There’s No Recipe for Success

TL&DR: There cannot be a simple and easy recipe for success, or everyone else would be using it.

My recent chat with David Bombal about networking careers’ future resulted in tons of comments, including a few complaints effectively saying I was pontificating instead of giving out easy-to-follow recipes. Here’s one of the more polite ones:

No tangible solutions given, no path provided, no actionable advice detailed.

I totally understand the resentment. Like a lot of other people, I spent way too much time looking for recipes for success. It was tough to admit there are none for a simple reason: if there was a recipe for easy success, everyone would be using it, and then we’d have to redefine success. Nobody would admit that being average is a success, or as Jeroen van Bemmel said in his LinkedIn comment:

Success requires differentiation, which cannot be achieved by copying others. As Steve Jobs put it: “Be hungry, stay foolish”

Worth Reading: Splitting the Ping

I hope you’re aware that the venerable ping (and most of its variants) measures round-trip-time – how long it takes to get to the destination and back – but is there a way to measure one-way latency or find out asymmetric transit times?

Ben Cox found a way to use ICMP timestamps together with reasonably accurate NTP-derived time to do just that. More details in Splitting the ping (HT: Drew Conry-Murray).

Worth Reading: Splitting the Ping

I hope you’re aware that the venerable ping (and most of its variants) measures round-trip-time – how long it takes to get to the destination and back – but is there a way to measure one-way latency or find out asymmetric transit times?

Ben Cox found a way to use ICMP timestamps together with reasonably accurate NTP-derived time to do just that. More details in Splitting the ping (HT: Drew Conry-Murray).

Interview: Is Networking Dead?

A few weeks ago I enjoyed a long-overdue chat with David Bombal. David published the first part of it under the click-bait headline Is Networking Dead (he renamed it Is There any Future for Networking Engineers in the meantime).

According to Betteridge’s law of headlines the answer to his original headline is NO (and the second headline violates that law – there you go ?‍♂️). If you’re still interested in the details, watch the interview.

1 86 87 88 89 90 178