Not Interested in Network Automation? No Problem (for now)
In the Business Impact of Network Automation podcast Ethan Banks asked an interesting question: “what will happen with older networking engineers who are not willing to embrace automation”
The response somewhat surprised me: Alejandro Salisas said something along the lines “they’ll be just fine” (for a while).
Let me recap his argument and add a few twists of my own:
Read more ...MPLS L3VPN: Label Following Fun with Fish
I have to admit I LOVE MPLS. I admit, I didn’t love it so much when I was first learning. I found it kinda hard at first. But then I absolutely loved it once I “saw” it. Newer to MPLS... Read More ›
The post MPLS L3VPN: Label Following Fun with Fish appeared first on Networking with FISH.
Worth Reading: There Are No Enterprises and Service Providers
Russ White wrote a great article along the lines of what we discussed a while ago. My favorite part:
There are companies who consider the network an asset, and companies that consider the network a necessary evil.
Enjoy!
On a tangential topic: Russ will talk about network complexity in the Building Next-Generation Data Center online course starting on April 25th.
The problem of unpredictable interface order in multi-network Docker containers
Whether we like it or not, the era of DevOps is upon us, fellow network engineers, and with it come opportunities to approach and solve common networking problems in new, innovative ways. One such problem is automated network change validation and testing in virtual environments, something I’ve already written about a few years ago. The biggest problem with my original approach was that I had to create a custom REST API SDK to work with a network simulation environment (UnetLab) that was never designed to be interacted with in a programmatic way. On the other hand, technologies like Docker have been very interesting since they were built around the idea of non-interactive lifecycle management and came with all API batteries already included. However, Docker was never intended to be used for network simulations and its support for multiple network interfaces is… somewhat problematic.
Problem demonstration
The easiest way to understand the problem is to see it. Let’s start with a blank Docker host and create a few networks:
docker network create net1
docker network create net2
docker network create net3
Now let’s see what prefixes have been allocated to those networks:
docker network inspect -f "{{range .IPAM.Config }}{{.Subnet}}{{end}}" Continue readingChatOps – more Ops?
In the recent years we observed several movements inside of Corporate IT – DevOps and NetOps are two big ones in my experience. Probably there are more. While the definition of those is constantly changing depending on who you talk to and what time of day. Recently I came across a new term – ChatOps. […]Link Propagation 108
Welcome to Link Propagation, a Packet Pushers newsletter. Link Propagation is included in your free membership. Each week we scour the InterWebs to find the most relevant practitioner blog posts, tech news, and product announcements. We drink from the fire hose so you can sip from a coffee cup. A note from Greg Why Link […]Show 379: Grappling With Promise Theory
Mark Burgess, who developed the principles of Promise Theory as a way to model distributed systems, joins the Packet Pushers to explore how his ideas connect to networking and information systems. The post Show 379: Grappling With Promise Theory appeared first on Packet Pushers.
Riverbed Gains Revenue Share in SD-WAN
Cisco and VMware change the SD-WAN playing field.
Nutanix Reports Strong Revenue, Buys Minjar, Plans Hyperconverged Cloud Domination
Minjar sells a service that compares costs across public clouds.
NSX Layer 2 VPN: Deploying for datacentre migrations
In my previous post, NSX Layer 2 VPN: Migrating workloads between Datacentres, I described the process and theory behind using an NSX Layer 2 VPN (L2VPN) to migrate workloads from a soon-to-be-retired VLAN backed datacentre, to an NSX Managed logical switch backed datacentre. In this post I will take you through the deployment of the L2VPN in my lab environment, following these high-level steps:
- Prepare the NSX Managed Site
- Deploy the Layer 2 VPN Server
- Prepare the Standalone Site
- Deploy the Layer 2 VPN Client
- Validate the Layer 2 VPN connectivity
Current lab environment
The Lab environment I am using currently reflects the diagram below, with two VMs deployed onto VLAN 20 within my “remote” site (my remote site is actually just a separate cluster from my “NSX Managed Site”, which is my workload cluster). In my NSX Managed site I have a Provider Logical Router (PLR) and Distributed Logical Router (DLR) configured.
Current lab layout
Configure the NSX Managed Site
To prepare the NSX Managed Site the L2VPN-Server needs to be connected to a “trunk” interface, which allows multiple VLAN or Logical Switches to be configured as sub-interfaces, rather than having an interface in each VLAN/Logical Switch.
The Continue reading
When Will BGP Become Unfashionable? – Video
If we're ever going to find a replacement for BGP, we'll need to build a community that draws interest and attention. Where will the next fashion come from?Is NAT a Bad Thing?
Peter Welcher examines the pros and cons of Network Address Translation and describes design scenarios.
Vodafone Finds Containers Drastically More Efficient Than VMs
Resource savings with containers is pegged at around 40 percent.
Engineering versus Metaengineering
In my latest short take over at the Network Collective, I explain the difference between engineering and metaengineering.
The Modern Telco is Open Series, Part 1: Open Telco Framework Q&A
Thanks to all who joined us for the first of The Modern Telco is Open Series, The Open Telco Framework. During the webinar, we saw how Red Hat’s open 5G architecture foundation helps modern telcos deploy new services (MEC apps, vRAN, IoT) – faster, economically and at massive scale. After the webinar, we had a live Q&A with... Read more →