Microsegmentation Terminology

While I liked reading the Where to Stick the Firewall blog post by Peter Welcher, it bothered me a bit that he used microsegmentation to mean security groups.

I know that microsegmentation became approximately as well-defined as cloud or SDN¹, but let’s aim our shiny lance ² at the nearest windmill and gallop away…

Microsegmentation Terminology

While I liked reading the Where to Stick the Firewall blog post by Peter Welcher, it bothered me a bit that he used microsegmentation to mean security groups.

I know that microsegmentation became approximately as well-defined as cloud or SDN¹, but let’s aim our shiny lance ² at the nearest windmill and gallop away…

netsim-tools: New in December 2021

Tons of new things were added to netsim-tools in December 2021:

• Pete Crocker contributed support for Fortinet devices. You can configure IPv4, IPv6 and OSPF. More details…
• Jeroen van Bemmel contributed support for Nokia SR Linux and SR OS (including initial device configuration, OSPF, ISIS, BGP, and SR-MPLS).
• I added Vagrant box names for IOSv, CSR and vSRX on VirtualBox. You still have to build the boxes, but at least you won’t have to change the default settings.

But wait, there’s more ;)

netsim-tools: New in December 2021

Tons of new things were added to netsim-tools in December 2021:

• Pete Crocker contributed support for Fortinet devices. You can configure IPv4, IPv6 and OSPF. More details…
• Jeroen van Bemmel contributed support for Nokia SR Linux and SR OS (including initial device configuration, OSPF, ISIS, BGP, and SR-MPLS).
• I added Vagrant box names for IOSv, CSR and vSRX on VirtualBox. You still have to build the boxes, but at least you won’t have to change the default settings.

That’s It for 2021

It’s hard to believe, but another year has swooshed by, and it’s time to shut down my virtual office and disappear until mid-January. Of course I’ll be around in case of urgent support problems – I will read my email, but won’t reply to 90% of the stuff coming in.

I hope you’ll be able to find a few days to disconnect from the crazy pace of networking world and focus on your loved ones. I would also like to wish you all the best in 2022!

That’s It for 2021

It’s hard to believe, but another year has swooshed by, and it’s time to shut down my virtual office and disappear until mid-January. Of course I’ll be around in case of urgent support problems – I will read my email, but won’t reply to 90% of the stuff coming in.

I hope you’ll be able to find a few days to disconnect from the crazy pace of networking world and focus on your loved ones. I would also like to wish you all the best in 2022!

Fast Failover: Marketing and Reality

I wanted to cover fast failover (at least the basics and Prefix Independent Convergence – PIC) in another live session of How Networks Really Work webinar in 2021, but unfortunately I ran out of time.

As a teaser, you might want to watch the recording of Fast Failover: Marketing and Reality presentation I had at the Seventh RSNOG Conference.

Fast Failover: Marketing and Reality

I wanted to cover fast failover (at least the basics and Prefix Independent Convergence – PIC) in another live session of How Networks Really Work webinar in 2021, but unfortunately I ran out of time.

As a teaser, you might want to watch the recording of Fast Failover: Marketing and Reality presentation I had at the Seventh RSNOG Conference.

Highlights: Dynamic Negotiation of BGP Capabilities

The Dynamic Negotiation of BGP Capabilities blog post generated almost no comments, apart from the #facepalm realization that a certain network operating system resets IBGP sessions when the sole EBGP session goes down, but there were a few interesting comments on LinkedIn and Twitter.

While most engineers easily relate to the awkwardness of bringing down a BGP session to enable new functionality (Tearing down BGP session, as a solution reminds me rebooting a host, as a solution.), it’s not as easy as it looks. As Adam Chappell put it “Dynamic capability renegotiation does tend to sound a bit like changing the tyres while still moving. Very neat if you can pull it off but so much to go wrong…”

Highlights: Dynamic Negotiation of BGP Capabilities

The Dynamic Negotiation of BGP Capabilities blog post generated almost no comments, apart from the #facepalm realization that a certain network operating system resets IBGP sessions when the sole EBGP session goes down, but there were a few interesting comments on LinkedIn and Twitter.

While most engineers easily relate to the awkwardness of bringing down a BGP session to enable new functionality (Tearing down BGP session, as a solution reminds me rebooting a host, as a solution.), it’s not as easy as it looks. As Adam Chappell put it “Dynamic capability renegotiation does tend to sound a bit like changing the tyres while still moving. Very neat if you can pull it off but so much to go wrong…”

Checking Network Device Configurations in a GitOps CI Pipeline

Here’s a fun fact network automation pundits don’t want to hear: if you’re working with replaceable device configurations (as we did for the past 20 years, at least those fortunate enough to buy Junos), you already meet the Infrastructure-as-Code requirements. Storing device configurations in a version control system and using reviews and merge requests to change them (aka GitOps) is just a cherry on the cake.

When I made a claim along these same lines a few weeks ago during the Network Automation Concepts webinar, Vladimir Troitskiy sent me an interesting question:

Checking Network Device Configurations in a GitOps CI Pipeline

Here’s a fun fact network automation pundits don’t want to hear: if you’re working with replaceable device configurations (as we did for the past 20 years, at least those fortunate enough to buy Junos), you already meet the Infrastructure-as-Code requirements. Storing device configurations in a version control system and using reviews and merge requests to change them (aka GitOps) is just a cherry on the cake.

When I made a claim along these same lines a few weeks ago during the Network Automation Concepts webinar, Vladimir Troitskiy sent me an interesting question:

Running Network Automation Tools in a Container

Setting up a network automation development environment is an interesting task:

• You have to install a half-dozen tools, each one with tons of dependencies;
• SSH libraries like paramiko have to installed manually;
• Ansible modules for individual network devices might need extra libraries;
• Parsing tools invoked with Ansible Jinja2 filters have to be installed separately;
• Add your pet peeve here ;)

Now imagine having to do that for a dozen networking engineers and software developers working on all sorts of semi-managed laptops. Containers seem to be one of the sane solutions¹.

Running Network Automation Tools in a Container

Setting up a network automation development environment is an interesting task:

• You have to install a half-dozen tools, each one with tons of dependencies;
• SSH libraries like paramiko have to installed manually;
• Ansible modules for individual network devices might need extra libraries;
• Parsing tools invoked with Ansible Jinja2 filters have to be installed separately;
• Add your pet peeve here ;)

Now imagine having to do that for a dozen networking engineers and software developers working on all sorts of semi-managed laptops. Containers seem to be one of the sane solutions¹.

Worth Reading: Snowflake Network Devices

In his latest blog post, Tom Hollingsworth compares network device disaggregations with cord cutting (replacing cable TV subscription with Netflix and friends), and comes to the inevitable conclusion:

The idea is that you gain freedom and cheaper software. The hope is that you can build an enterprise network for half of what it would normally cost. The reality is that you’re going to gain less functionality and spend more time integrating things together on your own instead of just putting in a turnkey solution.

To rephrase it, you’ll design a snowflake network with snowflake devices. Good job – just because it makes sense for the FAANG club (or LinkedIn), it doesn’t mean you should be doing it.

Worth Reading: Snowflake Network Devices

In his latest blog post, Tom Hollingsworth compares network device disaggregations with cord cutting (replacing cable TV subscription with Netflix and friends), and comes to the inevitable conclusion:

The idea is that you gain freedom and cheaper software. The hope is that you can build an enterprise network for half of what it would normally cost. The reality is that you’re going to gain less functionality and spend more time integrating things together on your own instead of just putting in a turnkey solution.

To rephrase it, you’ll design a snowflake network with snowflake devices. Good job – just because it makes sense for the FAANG club (or LinkedIn), it doesn’t mean you should be doing it.

Podcast: Ironing Out the BGP Ruffles

After the (in)famous October 2021 Facebook outage, Corey Quinn invited me for another Screaming in the Cloud chat, this time focusing on what went wrong (hint: it wasn’t DNS or BGP).

We also touched on VAX/VMS history, how early CCIE lab exams worked, how BGP started, why there are only 13 root name servers (not really), and the transition from networking being pure magic to becoming a commodity. Hope you’ll enjoy our chat as much as I did.

Podcast: Ironing Out the BGP Ruffles

After the (in)famous October 2021 Facebook outage, Corey Quinn invited me for another Screaming in the Cloud chat, this time focusing on what went wrong (hint: it wasn’t DNS or BGP).

We also touched on VAX/VMS history, how early CCIE lab exams worked, how BGP started, why there are only 13 root name servers (not really), and the transition from networking being pure magic to becoming a commodity. Hope you’ll enjoy our chat as much as I did.

Response: Hardware Differences between Routers and Switches

Dmytro Shypovalov sent me his views on the hardware differences between routers and switches. Enjoy!

So, a long time ago routers were L3 with CPU forwarding and switches were L2 with ASIC. Then they had invented TCAM and L3 switches, and since then ASICs have evolved to support more features (QoS, encapsulations etc) and store more routes, while CPU-based architectures have evolved to specialised NPU and parallel processing (e.g. Cisco QFX) to handle more traffic, while supporting all features of CPU forwarding.

Response: Hardware Differences between Routers and Switches

Dmytro Shypovalov sent me his views on the hardware differences between routers and switches. Enjoy!

So, a long time ago routers were L3 with CPU forwarding and switches were L2 with ASIC. Then they had invented TCAM and L3 switches, and since then ASICs have evolved to support more features (QoS, encapsulations etc) and store more routes, while CPU-based architectures have evolved to specialised NPU and parallel processing (e.g. Cisco QFX) to handle more traffic, while supporting all features of CPU forwarding.